WHMCS.Community

The logs are showing both these entries are coming from the new Stripe Dynamic Payments module. The only endpoint is stripe_dynamic.php. We also updated to the latest Stripe API version for testing. We did find that removing the payment.failed destination event from within Stripe stops the "failed" WHMCS entry and the declined charge entry still shows. We are still testing to see whether this causes an issue as having 3 destination events seems to be the default. Is anyone  using charge.failed, charge.succeeded, and payment_method.updated as destination events and not seeing the "failed" entry on declined payments?

That seems unlikely, with the product itself being EOL'ed almost 10 years ago. Before they ended the support and updates "product",  it was a fairly expensive thing. Though not impossible they bought a pile of them, I'd think that's not plausible, especially since they'd likely have updated since if they could have. Maybe. 

That "resolving to the wrong IP" line is a bit of a red herring. The curltest script compares the lookup against a short list of IPs hardcoded into the script, and that list has gone stale more than once over the years as WHMCS moved its licensing infrastructure. 104.20.36.75 and 172.66.151.35 are exactly what whmcs.com resolves to from anywhere right now, so your server's DNS isn't being hijacked. Don't let anyone "fix" it by pinning whmcs.com to another IP in /etc/hosts; that's the one thing that really would look like a bypass. What I'd check, in this order: 1. Can the server actually complete an HTTPS request to WHMCS? From SSH as the user WHMCS runs under, run: curl -sv https://www.whmcs.com/ -o /dev/null On a box old enough to still run WHMCS 6 (PHP 5.x era), the usual failure is the TLS handshake or an outdated CA bundle, not DNS. If curl from the shell works but PHP's curl doesn't, the PHP build's OpenSSL is the problem. 2. Log in to your account at whmcs.com and look at the license itself: status Active, and the Valid Domains/IPs/Directory match where the install lives now. If the server IP changed recently, a reissue from the client area clears that. 3. If both of those are fine, open a ticket with WHMCS licensing, give them the license key, and ask straight out whether 6.x installs can still validate against the current licensing servers. They can see the failed check attempts on their side, which beats guessing. On the upgrade question: whatever the root cause turns out to be, 6.x is many years past end of life and only runs on PHP versions that stopped getting security fixes a long time ago, so plan the upgrade either way. With an owned license, check whether your Support & Updates is still active; if it lapsed, you'll need to renew it before you can download current versions. Do the jump on a copy of the site and database first, since going from 6 to current means moving through several major versions and PHP versions, and any custom templates or old modules will need checking along the way.

Yes, using a hook would be a better solution if WHMCS does not address this issue. However, I believe this should be fixed in an upcoming WHMCS release.  

Nice find on the Chrome password manager, d9hosting. That also explains why some people never see it: it only hits staff who have the admin login saved in Chrome. One suggestion on ThemeMetro's fix: rather than editing viewticket.tpl in the Blend template, drop the same script into a hook. Template edits get overwritten on the next WHMCS update, while a file in includes/hooks/ survives updates and you don't have to remember to re-apply it. Something like this: <?php // includes/hooks/ticket_status_autofill_fix.php add_hook('AdminAreaFooterOutput', 1, function ($vars) { if (basename($_SERVER['SCRIPT_NAME']) !== 'supporttickets.php') { return ''; } return <<<'HTML' <script> // paste ThemeMetro's script body here, from "// Prevent Chrome Password Manager autofill" down to the setTimeout lines </script> HTML; }); Their script already returns early when the status field isn't on the page, so it's harmless on the ticket list. After adding it, hard refresh a ticket (Ctrl+Shift+R) and check the status box no longer gets the username dropped into it. Worth adding d9hosting's finding to a WHMCS ticket as well, so the status field markup gets fixed in core, since this affects anyone using Chrome's built-in password manager.

WHMCS 8 removed the ability for administrators to change a user's password from the admin area. Change User Password puts it back, safely and with every action recorded. Change a password straight from the client profile or from the Manage Users dropdown, generate a strong password with one click, and optionally email it to the user so they can log in right away. Owned License ($30.00) - https://www.hardsoftcode.com/cart/link/change-user-password-for-whmcs/owned Source Code License ($200.00) - https://www.hardsoftcode.com/cart/link/change-user-password-for-whmcs/source Why you need it Users ask support to reset their password, and WHMCS no longer lets you do it. Staff can reset passwords without ever needing the old one. Every change is logged with who did it, when and from where. Highlights Two places to change a password: the client profile tab and the Manage Users dropdown, using the native WHMCS modal. Built-in password generator: configurable length (8–64) and character types, using a cryptographically secure random source. Optional email to the user: sent with a ready-made Change User Password template. Dashboard and activity log: KPI cards, a reset trend chart, and a full audit trail with IP and browser. Role-based access: uses the built-in WHMCS Access Control list, enforced server side. Secure by design: POST-only, CSRF-protected endpoints, and no passwords in the logs. Works on WHMCS 8.x and 9.x. Admin area only, no client-area changes. What's New This release makes the module's modal endpoints POST-only with CSRF validation. Opening an endpoint URL directly in the browser now returns the standard WHMCS HTTP Method Not Allowed page, just like WHMCS core routes. CSRF checks also go through one shared, fail-closed helper, so the modal shows a clean error instead of a raw response. Access control now uses the built-in WHMCS Access Control list, and existing role lists are migrated automatically. The dashboard has been redesigned with total, monthly and daily reset counters, a quick action bar, a 7 / 30 / 90 day or all-time filter, and a new Reset Trend chart. Endpoints are now root-relative so they work from WHMCS 9 pretty admin URLs, and security was hardened across all endpoints and files. You can now choose which character types the password generator uses (letters, numbers and symbols), and passwords are generated with a cryptographically secure random source. This release also fixes the Generate button and the CSRF token on the save form, so new passwords save correctly. Features Change a password Change a password from the client profile tab Change a password from the client profile → Users tab Change a password from Clients → Manage Users One click to change a password in a native WHMCS modal Send an email notification to the user with the new password Works with WHMCS 9 pretty URLs Password generator Configurable password length (8–64) Configurable character types: letters, numbers, symbols At least one character of every selected type Cryptographically secure random generation Copy and Insert buttons Admin and audit Dashboard with total, monthly and daily reset counters Reset Trend chart with 7 / 30 / 90 day and all-time filters Activity log with actor, IP and browser user-agent Settings history that names every changed value Configurable log retention with automatic cleanup Security and access Role-based access control using the WHMCS Access Control list POST-only, CSRF-protected endpoints No passwords stored in the activity log or the email log No changes to WHMCS core files Email Ready-made Change User Password email template Changelog v2.4.1 Added: Three dashboard KPI cards: Total Resets, This Month and Today's Resets Added: Quick action bar: generate a test password, find a client, settings Added: 7 / 30 / 90 day and all-time activity filter Added: Reset Trend chart, capped at 366 days for All Time, with Chart.js 4.4.1 bundled (no CDN) Added: Password Characters setting: choose letters, numbers and symbols Added: Every selected character type is guaranteed in each generated password Added: Dashboard, Activity Log (DataTables) and admin header navigation Added: Audit log with IP and browser Added: Per-change settings history Added: AJAX settings with toast messages Updated: Modal body (a=index) is now POST-only with a CSRF token, like WHMCS core routes Updated: Opening an endpoint URL directly in the browser returns the WHMCS HTTP Method Not Allowed page Updated: Access Control now uses the built-in WHMCS role list, and the module's own role field was removed Updated: Existing role lists are migrated automatically, and an empty role list denies access, matching WHMCS Updated: Dashboard redesigned, with the activity feed sorted by date, capped at 10 rows and showing actor badges Updated: Endpoints are root-relative, so they work from WHMCS 9 pretty admin URLs Updated: Password generation is now cryptographically secure (random_int() + Fisher-Yates) instead of str_shuffle() Updated: Modern rewrite on the HSCode architecture: namespaced controllers and Smarty admin templates Fixed: Direct GET to a=store and a=password now returns the WHMCS 405 page instead of a bare JSON error Fixed: GET responses no longer mint or echo a CSRF token Fixed: Dashboard counters now count password changes only, so settings saves no longer inflate them Fixed: Generate button now works Fixed: CSRF token on the save form, so new passwords save correctly Fixed: Generator modal no longer reuses WHMCS element IDs Fixed: Length warning and pre-filled password Improved: CSRF validation is centralised in one fail-closed helper that returns a clean JSON 403 to the modal Improved: a=store and a=password use the same CSRF helper Improved: Access is enforced consistently in the UI and the endpoints Improved: Security hardening: POST-only password generation, password saves and settings saves, restricted controller dispatch, password length and NUL byte checks, direct file access blocked, .htaccess rules, and generic activation and deactivation errors

That string ships in WHMCS's own language files (it's the FAQ text on the MarketConnect SocialBee store page), which is why grep finds it in every lang file. The value has "href=" doubled inside the quotes, so browsers treat it as a relative link and the "calls" link ends up pointing at a path on your own WHMCS domain instead of socialbee.com. Your sed fix works, but I wouldn't leave it there: lang/english.php and the other core lang files are replaced on every WHMCS update, so the broken link quietly comes back. Language overrides survive updates: 1.  Create the folder lang/overrides/ if it doesn't exist, then a file lang/overrides/english.php that starts with <?php 2. Add just the corrected key: $_LANG['store']['socialbee']['faq']['a2']['i2'] = "Support through <a href='https://socialbee.com/calendar/'>calls</a>, chat, or email communication. We’re one of the few social media tools still offering on-call support."; 3. Do the same for each language you actually have enabled (lang/overrides/farsi.php, lang/overrides/arabic.php and so on). Override files only need the keys you're changing; everything else still loads from the main file. Then load the SocialBee store page with that language selected and hover the link to confirm it now goes to socialbee.com. It's also worth reporting it to WHMCS as a bug so it gets corrected in the shipped files, since every install with MarketConnect has the same broken link.

As a temporary fix, you may edit the viewticket.tpl file manually and replace the last script block with the updated code in blend template. From <script> $(document).ready(function() { if (typeof aiRating !== 'undefined') { aiRating.init(); } }); </script> To <script> $(document).ready(function() { if (typeof aiRating !== 'undefined') { aiRating.init(); } // Prevent Chrome Password Manager autofill in Status Selectize function fixStatusAutofill() { var statusSelect = document.querySelector( '#frmAddTicketReply select[name="status"].selectized' ); if (!statusSelect) { return; } var statusInput = statusSelect.nextElementSibling ? statusSelect.nextElementSibling.querySelector('input') : null; if (!statusInput) { return; } statusInput.setAttribute('autocomplete', 'off'); statusInput.setAttribute('data-lpignore', 'true'); statusInput.setAttribute('readonly', 'readonly'); function clearInvalidValue() { var currentValue = statusInput.value.trim(); var validOption = Array.from(statusSelect.options).some(function(option) { return option.text.trim().toLowerCase() === currentValue.toLowerCase(); }); if (currentValue && !validOption) { statusInput.value = ''; statusInput.dispatchEvent(new Event('input', { bubbles: true })); } } clearInvalidValue(); if (!statusInput.dataset.autofillFixed) { statusInput.addEventListener('focus', function() { clearInvalidValue(); statusInput.removeAttribute('readonly'); setTimeout(clearInvalidValue, 100); }); statusInput.dataset.autofillFixed = 'true'; } } fixStatusAutofill(); setTimeout(fixStatusAutofill, 500); setTimeout(fixStatusAutofill, 1500); }); </script>    

Hi So what prompted this was my AI automation. I have AI compile details on security updates several times a day - giving us prompt warning of any action we need to take to secure our servers.   Part of the work it does is checking all the relevant places for updates, mitigation steps etc for our entire stack. The AI stumbled upon this blog post and set alarm bells off. We checked the link it provided and sure enough  - there it was a page published about Lagom and others on the 21st. So yeah, perhaps dont pubish till its ready. 

Indeed that is the case, strange that other clients do not have this issue, maybe I switched too fast to a new solution that is not working properly, yet.