When a serious software flaw lets attackers run code on a system, or skip login entirely, installing the patch is only half the job. Anyone who got in before the fix, or during the public exploit window, may have copied passwords, session tokens, API keys, encryption keys, or other secrets that lived on that system or briefly sat in memory.
Security guidance from CISA, vendors, and incident responders often treats that system as potentially compromised until those credentials are rotated: changed and the old ones invalidated.
This post explains that gap in plain language, walks through recent October 2026 examples that commonly trigger rotation, and shows why a reused password on a "less important" site can still put your business at risk. It sits next to our guide on vulnerability management before AI and our playbook for faster patching, MFA, and password hygiene with governed AI.
Not sure what was exposed in your environment? Get a free cybersecurity assessment and see your patching gaps, identity gaps, and fastest risk reductions.
What these flaws mean in everyday terms
Many of the issues below are remote code execution (RCE) or authentication bypass flaws.
- An RCE is like leaving a building's back door unlocked so a stranger can walk in and run the computers inside without a key.
- An authentication bypass is like a broken lock that lets someone claim to be an authorized person and open the door anyway.
Once inside, attackers can read configuration files, database passwords, API keys used to talk to other services, session cookies that keep people logged in, or data sitting in short-term memory. They can also plant malware that steals more credentials later.
CISA's Known Exploited Vulnerabilities (KEV) catalog lists flaws with evidence of real-world attacks. Federal agencies must prioritize them, and everyone else should treat KEV items on internet-facing systems as urgent: patch fast, then check whether compromise happened before the patch landed.
That "check and rotate" step is what most teams skip. Our basics cycle for vulnerability management with verified closure covers inventory, scan, prioritize, patch, and rescan. Credential rotation is the identity twin of verified closure: you do not just close the hole, you replace the keys that may have been copied through it.
Recent examples that often call for credential rotation
Here are prominent October 2026 issues (and closely related ones) where patching alone is often not enough. Always confirm fixed versions and recovery steps in the vendor advisory and CISA alert for your exact product build.
1. PHP2Shell (CVE-2026-109618 and CVE-2026-109619)
Critical flaws in PHP, which powers a large share of websites. In many common setups, an attacker on the internet can run their own code on the web server without logging in. Researchers showed it is possible to read server memory, where passwords, API keys, and other secrets can briefly exist before they are hashed or encrypted.
What to do: Patch to the fixed PHP versions listed in the PHP project advisory (commonly cited builds include 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later; verify against the current advisory). If the server was internet-facing and unpatched during the vulnerable window, treat it as potentially compromised. Rotate database passwords, application secret keys (for example WordPress salts), API keys for email, payments, or cloud services, and session secrets the PHP process could see. A patch does not undo prior access.
2. GitLab self-managed (CVE-2026-110264, CVSS 10.0)
A maximum-severity flaw affecting many self-managed Community and Enterprise Edition versions. Under certain conditions, an unauthenticated attacker could run code by triggering an integer overflow when the system compiles a specially crafted regular expression.
Successful exploitation can give the attacker the same access as code running as the git user, which commonly includes files such as gitlab-secrets.json, CI/CD variables (often passwords and API keys), runner tokens, and deploy keys. GitLab released emergency patches around 21 October 2026 (example trains such as 19.5.1, 19.4.3, 19.3.6, 18.11.13 and related backports; confirm the advisory for your version). An earlier mid-October regex fix did not fully cover this issue.
What to do: Upgrade immediately. If there are signs of compromise, or the instance was internet-facing and unpatched, rotate CI/CD secrets, runner tokens, deploy keys, and other credentials stored in or accessible to that GitLab instance.
3. Ivanti Connect Secure (CVE-2026-104935, authentication bypass, actively exploited)
A VPN appliance vulnerability (added to CISA's KEV catalog around 13 October 2026) that lets a remote attacker bypass login and run commands. Real-world attackers have chained it with other issues for deeper access. Reported outcomes include theft of credentials stored on the appliance (including LDAP or domain service accounts), Active Directory searches for local administrator passwords (LAPS) and BitLocker recovery keys, and related credential attacks.
What to do: Patch to fixed versions. CISA and incident responders note that recovery after confirmed or suspected compromise typically includes resetting account passwords, rotating the appliance's Active Directory service account and any stored domain credentials, and reissuing certificates, API keys, or license credentials.
4. Cisco Secure Email Gateway (CVE-2026-76519, CVSS 9.8, actively exploited)
A flaw in the Advanced Malware Protection feature that can allow an unauthenticated attacker, under certain conditions, to send a crafted email attachment and write files or run commands as root on the gateway. Cisco has confirmed active exploitation; CISA added it to the KEV catalog.
What to do: Apply the vendor patches or Content Scanner Tools update. Because root access can expose credentials and configurations on the device, review and rotate relevant admin credentials, API keys, and linked service accounts if the appliance was exposed.
5. Other recent issues with the same pattern
- Plex Media Server "Plex2Shell" chain (multiple CVEs added to CISA KEV around 20 October 2026): Chained flaws enable remote code execution on internet-facing media servers. Attackers have used them for cryptominers and proxy malware. Malware that runs on the host can also hunt local passwords, browser-saved credentials, or keys.
- Arista VeloCloud Orchestrator (CVE-2026-114625, CVSS 9.9): Authenticated SQL injection that can let low-privilege users escalate to full operator control of the SD-WAN management system.
- Management-interface or appliance RCEs in products such as Palo Alto PAN-OS, Fortinet, and BeyondTrust Remote Support that appear in recent CISA KEV updates can similarly lead to credential exposure once an attacker has a foothold.
In all of these cases, CISA guidance tied to Binding Operational Directive style KEV requirements emphasizes rapid patching of listed issues on exposed systems and checking whether compromise occurred before the patch was applied.
Want help turning this into a repeatable process? Explore BTI's managed cybersecurity services for scanning, prioritized remediation, verified closure, and 24/7 monitoring.
Why a reused password on a "common site" still hurts you
Many people carefully use unique, strong passwords and multi-factor authentication (MFA) on their most important accounts (bank, email, work). That is excellent practice. Password reuse is still common for lower-priority or "convenience" sites: forums, smaller web apps, older self-hosted tools, media servers, or PHP apps.
Here is the practical risk:
Imagine the same password (or a slight variation) is used on a self-hosted tool later hit by one of the flaws above. An attacker who gains code execution or reads memory can extract that password, then try it against other services (credential stuffing). Your bank or email was not broken by the original vulnerability. The reused secret became the key that worked elsewhere.
MFA stops many of these attempts. It is not perfect in every scenario: some services still allow password-only login, attackers sometimes steal session tokens that already passed MFA, or they phish the second factor. API keys and long-lived tokens on a compromised server are especially dangerous because they often bypass normal login flows entirely.
The safest habits, which we expand in Governed AI for IT: Faster Patching, MFA, and Passwords, are:
- Unique passwords (or a business password manager) for every site and system.
- MFA everywhere it is available, preferably with an authenticator app or hardware security key rather than SMS.
- Treating any system that was vulnerable and internet-facing during the exploit window as potentially compromised until you have rotated the secrets it held.
A practical "patch then rotate" checklist
Use this after any KEV-listed or critical internet-facing flaw on systems you own:
- Confirm the version and the fix. Match your build to the vendor advisory. Apply the patch or compensating control.
- Verify the hole is closed. Rescan or retest. A ticket marked done is not proof. That is the same verified-closure idea we use in vulnerability management.
- Inventory secrets that lived on the box. Admin passwords, service accounts, database credentials, application secrets, CI/CD variables, API keys, certificates, VPN or appliance domain accounts, session signing keys.
- Rotate and invalidate. Change each secret and revoke the old one. Prefer short-lived tokens going forward where the product allows it.
- Tighten identity. Enforce MFA on admin and remote access paths. Move high-value accounts to phishing-resistant security keys when you can.
- Watch for follow-on abuse. Review logs for unusual logins, new local accounts, unexpected outbound connections, and new scheduled tasks or services.
- Keep evidence. Record what was patched, what was rotated, who approved exceptions, and when rescans cleared. Auditors and insurers ask for this later.
Lean teams often stall on steps 3 to 5 because the list is long and manual. That is where governed AI can help triage which systems match a new disclosure, flag accounts without MFA, and draft rotation and rollout plans, with people still approving the changes that matter.
How BTI helps
BTI Communications Group has supported organizations for over 40 years. We help mid-market and multi-site teams close the gap between "we patched" and "we actually reduced risk."
Hand off the program. Our outsourced IT services with vulnerability management and 24/7 SOC run security end to end.
Add depth to your team. Co-managed security and compliance execution puts BTI technicians and security operations alongside your people, with clear ownership of who patches, who rotates secrets, and who verifies closure.
Faster triage, human accountability. Technicians use AI-enabled tools to match new disclosures to your assets, prioritize by exploitability and exposure, and draft remediation and rotation steps. A named technician owns each remediation, exception, and closure.
Around-the-clock detection. Our SOC 2 Certified NOC/SOC monitors logs and alerts 24/7 through our SIEM, investigates suspicious activity, and escalates with context.
Compliance-minded evidence. BTI is ISO 27001 compliant. We keep scan records, tickets, exceptions, and closure evidence organized. CMMC and other compliance work is completed and contracted by BTI and its partners, including top industry professionals in each category.
Frequently asked questions
When is credential rotation required after a vulnerability? When the flaw allows remote code execution, authentication bypass, or other access that could expose files, memory, configs, or stored secrets, especially on internet-facing systems listed in CISA's KEV catalog. When in doubt after a public exploit window, rotate the secrets that system could see.
Is patching enough if we have no proof of compromise? Patching closes the hole going forward. It does not prove nobody got in earlier. For high-severity, internet-facing, actively exploited issues, treat "no proof" as incomplete. Inventory secrets, rotate the high-value ones, and review logs.
How does this relate to MFA and password managers? Unique passwords and MFA limit how far a stolen credential travels. They do not replace rotation of secrets that already lived on a compromised host, especially API keys and service accounts that skip interactive login. See our MFA and password hygiene guide.
Can governed AI help with rotation and MFA rollouts? Yes, when it runs under clear permissions, human approval for important changes, and logging. It can match disclosures to assets, flag identity gaps, and draft rollout plans so a small team can move faster. Find out about BTI's Governed AI Services.
Bottom line
Patch first, especially anything in CISA's KEV catalog or flagged as critical by the vendor. Then inventory and rotate passwords, MFA recovery codes, API keys, service-account credentials, CI/CD secrets, and similar items that lived on or passed through affected systems. Official vendor advisories and CISA alerts are the authoritative sources for fixed versions and recovery steps.
If you run self-hosted GitLab, PHP-based websites, VPN or email gateways, or other internet-facing appliances like the ones above, check your versions today. When in doubt after a potential exposure, assume the worst on the credential side and rotate.
Get a clear picture of your exposure. Get a free cybersecurity assessment or talk with our cybersecurity team.
