September 2026 cybersecurity news: Forged tokens and leaked keys

September 2026 cybersecurity news was dominated by forged tokens, replayed sessions, and leaked API keys that kept working after the password was changed or never needed. Two vulnerabilities are already on CISA's Known Exploited Vulnerabilities list, and one leaked vendor key put 100,000+ sites at risk.

• Cisco ISE: CVE-2026-76460, an authentication bypass with confirmed active exploitation (Cisco).
• EvilTokens: Microsoft disrupted a device-code phishing service linked to more than 12,000 compromised inboxes across over 10,000 organizations (Microsoft).
• Brevo and Cloudflare: a compromised API key put more than 100,000 sites at potential risk (Sansec).
• JFrog Artifactory: a flaw exploited in honeypots to mint administrator tokens (SecurityWeek).
• Cleo Harmony: a public exploit for a JWT refresh-token flaw (SecurityWeek).
• CyberArk: 10 security bulletins on four dates, including one Critical (CyberArk).
• GitHub App keys: GitGuardian found 474 of 4,802 leaked private keys still valid, authenticating as 440 apps (GitGuardian).
• NIST IR 8587: final guidance on protecting tokens and assertions, published September 15 (NIST).

Each case below shows a different way a credential keeps working after it should have stopped: forged, replayed, leaked, or minted on demand. Details, affected versions, and fixes follow, with a short list of team-level actions at the end.

Active exploitation of an authentication bypass in Cisco Identity Services Engine (CVE-2026-76460)

Cisco published an advisory on September 16, 2026 for CVE-2026-76460, a critical, unauthenticated authentication-bypass vulnerability in an Identity Services Engine (ISE) API. Cisco rates it CVSS 3.1 Base 10.0 (Critical) and confirmed active exploitation. CISA added the CVE to its Known Exploited Vulnerabilities catalog the same day.

What happened: A crafted request to the affected API endpoint lets an attacker bypass ISE's web-based management interface and gain unauthorized access to an affected ISE or ISE-PIC device, without valid credentials. Cisco's PSIRT confirmed it was aware of in-the-wild attacks. The exact date exploitation began has not been disclosed.

Why it matters: ISE is a network-access policy platform. Unauthorized access could create serious deployment-specific risk to administration and policy operations, but the available sources don't establish that every customer's downstream RBAC or MFA decisions were altered. Impact depends on how a given organization has ISE deployed.

The defensive takeaway: Cisco says no workaround addresses the flaw. Upgrading to a fixed release is the complete remediation. As a temporary mitigation, Cisco recommends infrastructure ACLs (iACLs) that allow only required management- and control-plane traffic to the affected device. Review each node's access.log for suspicious usernames and cross-check network and firewall logs outside the appliance itself. These are detection and response steps, not a substitute for patching.

Sources: Cisco; CISA KEV

Microsoft disrupts EvilTokens, an OAuth device-code phishing service

On September 22, 2026, Microsoft's Digital Crimes Unit, working with partners, disrupted infrastructure behind EvilTokens, a phishing-as-a-service platform linked to more than 12,000 compromised inboxes across over 10,000 organizations worldwide.

What happened: EvilTokens abused OAuth 2.0 device-authorization flows, the mechanism designed for devices without a browser, such as smart TVs or CLI tools, to trick users into approving a sign-in on the attacker's behalf. Microsoft separately disclosed passkey-themed social-engineering activity observed since May 2026. In one investigated sequence, a passkey lure led to device-code phishing. In other investigated patterns, attackers used help-desk pretexts or registered attacker-controlled authentication methods. Microsoft's reporting doesn't establish that every sequence combined all of these steps into one attack chain.

Why it matters: Device-code phishing sidesteps the parts of authentication that get the most defensive attention. There's no fake login page to spot and no password typed into an attacker's site. The victim approves the sign-in through Microsoft's own legitimate page, believing it's routine. That said, a victim without an active Microsoft session can still be prompted for a real password and MFA challenge, so this technique doesn't universally erase every authentication step.

The defensive takeaway: Disable device-code authentication flows for users who don't operationally need them, and monitor for abnormal device-code sign-in volume as a detection signal. Where the flow is genuinely required, gate it behind conditional-access policy.

Sources: Microsoft; Microsoft (passkey-themed activity)

A single overprivileged Cloudflare API key put 100,000+ sites at risk

On September 14, 2026, attackers used a compromised, broadly privileged Cloudflare API key belonging to email and marketing platform Brevo to deploy a malicious Cloudflare Worker that altered Brevo-embedded assets on customer sites.

What happened: Sansec's telemetry recorded the malicious Worker serving content from 16:05 to 20:13 UTC on September 14, roughly four hours. Brevo's incident write-up describes the Worker as active for about five and a half hours, a longer window than Sansec directly observed. Sansec estimated that more than 100,000 sites using affected Brevo components may have been exposed to malicious content during that period.

Why it matters: One long-lived, full-permission Cloudflare API key, tied to a marketing-automation vendor, became a distribution channel for malicious code across a large number of third-party sites. Cloud API keys with broad scopes and no expiration are exactly the credential type that traditional password policy doesn't cover.

The defensive takeaway: Scope API keys to the minimum permission set an integration actually needs, set expirations even on service-level keys, and run continuous secret scanning across repositories and deployment pipelines, not just employee password vaults. Monitoring for unexpected Worker deployments or routing changes would likely have caught this faster than a manual audit.

Sources: Sansec; Brevo

JFrog Artifactory flaw used to mint admin tokens (CVE-2026-82329)

JFrog published a fix for CVE-2026-82329 on August 28, 2026. On September 1, WatchTowr reported honeypot activity consistent with attackers exploiting the flaw to generate administrator tokens.

What happened: WatchTowr's honeypots captured exploitation attempts against a small number of source IPs, some of which appeared to be verification-only activity rather than follow-through attacks. That's evidence the vulnerability is exploitable and being probed. It doesn't establish broad scanning across the internet or confirmed mass exploitation of customer instances.

Why it matters: Artifact repositories sit near the center of the software supply chain. They hold federation trust relationships with other repositories and often carry embedded credentials for downstream systems. An attacker who can generate an admin token doesn't need to steal one, they create valid access on demand.

The defensive takeaway: For self-hosted Artifactory, upgrade to the fixed release for your branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. JFrog says affected cloud environments were already fortified. If logs show exploitation or suspicious token issuance, revoke and reissue potentially exposed admin tokens and audit federation configurations. The available reporting supports honeypot-observed exploitation, not confirmed compromise of customer instances.

Sources: JFrog; SecurityWeek

Public exploit for a JWT refresh-token flaw in Cleo Harmony (CVE-2026-84115)

A public exploit for CVE-2026-84115 was reported on September 2, 2026, shortly after the CVE record was published on September 1.

What happened: The flaw affects Cleo Harmony versions through 5.8.1.10 and is fixed in Harmony 5.8.1.11. The CVE record describes a remotely exploitable issue in the /api/connections JWT Refresh Token Handler: manipulating the Bearer argument results in improper privilege management. SecurityWeek describes the same issue as allowing authentication bypass and privilege elevation. The available reporting establishes public exploitability and researcher reproduction. It doesn't establish confirmed exploitation of customer systems, nor that a manipulated token persists beyond the original session's expiry.

Why it matters: Refresh tokens are meant to extend a session quietly, without forcing a fresh login. A flaw in how one is validated turns that convenience feature into a potential persistence risk, which is reason enough to patch even without confirmed exploitation.

The defensive takeaway: Upgrade to Harmony 5.8.1.11 promptly. If exposure is suspected, follow Cleo's current guidance, review authentication and privilege changes from the relevant window, and revoke outstanding refresh tokens where the deployment supports that control. A public exploit's existence doesn't by itself confirm compromise or persistent access.

Sources: NVD; SecurityWeek

CyberArk ships ten security bulletins across its PAM product line

CyberArk released 10 security bulletins in September 2026, in four dated batches.

What happened: CyberArk released 10 security bulletins in four batches during September 2026, addressing High-severity issues across endpoint privilege management agents, self-hosted gateway and vault components, privileged-access analytics, and database credential management, as well as a Critical issue—CA26-44—affecting certain self-hosted Password Vault Web Access (PVWA) versions.

Why it matters: PAM systems often manage or provide access to privileged credentials and sensitive infrastructure. A concentrated set of security updates is a reminder that these environments require continuous patch management, clear access governance, and reliable auditability. The advisories do not, by themselves, indicate active exploitation.

The defensive takeaway: Organizations using affected products should review the advisories and prioritize remediation according to severity, exposure, and the potential impact on credential-related systems. More broadly, security teams should maintain visibility into who can access sensitive credentials and be able to review that access when needed.

Source: CyberArk; CyberIAM bulletin board

Leaked GitHub App private keys keep working long after exposure

GitGuardian tested 4,802 leaked GitHub App private keys found in public sources and found 474 still authenticating as 440 distinct live apps.

What happened: A GitHub App private key has no automatic expiry and can remain usable until it's manually revoked or deleted. Among the 474 still-valid keys GitGuardian tested, 207 carried repository content-write permission, 40 could administer self-hosted runners, 98 could control workflows, and 44 held organization-administration privileges. A key committed years ago may still authenticate if it hasn't been revoked or deleted.

A related pattern surfaced in a WSO2 API-management flaw, CVE-2026-5430. The advisory dates to May 2026 and the CVE was published in August. The September news was exploitation reporting, not a new disclosure. An attacker can craft a JWT with an unsupported signing algorithm and exploit WSO2's faulty validation to bypass authentication. The service doesn't need to mint a token itself. WatchTowr's honeypot captured administrator-privilege forged JWTs against it on September 13, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on September 24. Backend credentials, consumer keys, or secrets were reported as potentially reachable, not confirmed stolen.

Why it matters: A public leak creates potentially persistent access until the key is revoked or deleted. It doesn't by itself prove the key was used or that data was accessed. The WSO2 case shows a related pattern one layer down the stack: an attacker doesn't need a leaked key at all if the validation logic itself can be tricked into accepting a forged one.

The defensive takeaway: Maintain an owner and a documented rotation/revocation process for every GitHub App key. If exposure is suspected or confirmed, generate a replacement and revoke or delete the old key promptly; periodic rotation reduces exposure time, though GitHub doesn't prescribe a universal schedule. For WSO2 deployments, apply the vendor's fix, review logs for the September exploitation window, and rotate credentials the API-management layer had access to.

Sources: GitGuardian; GitHub docs; WSO2 advisory; The Hacker News

NIST and CISA finalize guidance on protecting identity and access tokens

NIST and CISA finalized IR 8587 on September 15, 2026, after an initial public draft dated December 22, 2025.

What happened: The implementation guidance is written primarily for federal agencies and the cloud service providers they use, covering identity tokens, access tokens, and assertions in SSO, federation, and API-access scenarios. Its recommendations summarize key-management, token-verification, lifecycle (including lifetime and revocation), and continuous-monitoring practices, with responsibilities divided between providers, consuming agencies, and cloud consumers.

Why it matters: Several of the failures described above, forged JWTs, admin tokens generated through validation flaws, non-expiring API keys, fall inside the categories this report addresses: verification gaps, missing lifecycle controls, and unclear provider-versus-customer responsibility for revocation. That overlap is useful even for organizations outside the federal space.

The defensive takeaway: Use NIST IR 8587 as a working checklist against current practices: confirm token lifetimes are bounded, revocation paths are tested rather than just documented, and session logging captures enough detail to reconstruct a token-based incident after the fact.

Sources: NIST; CISA

CloudSEK details BigBear 2.0, an adversary-in-the-middle service that replays Microsoft 365 sessions after MFA

CloudSEK published its BigBear 2.0 research on September 7, 2026. Its TRIAD team discovered the operation in June, which doesn't establish when all campaign activity began.

What happened: The Evilginx2-based adversary-in-the-middle service relayed Microsoft 365 sign-ins. It captured credentials and the Microsoft-issued session cookie after victims completed MFA, then let attackers replay the authenticated sessions. CloudSEK's panel contained 4,148 session-cookie records and 474 completed MFA-bypassed authentications. BleepingComputer reported that 258 distinct organizations had at least one such completed compromise, while 461 organizations appeared in the broader targeting dataset. The 4,148 figure is a cookie-record count, not a confirmed count of unique victims. (CloudSEK; BleepingComputer)

Why it matters: MFA that the victim completes on a proxied page protects nothing once the session cookie is stolen. The attacker inherits an already authenticated session. Codes and push approvals don't stop this pattern.

The defensive takeaway: Prioritize phishing-resistant methods such as passkeys and FIDO2 security keys for administrators and high-risk users. Review conditional access policies that bind sessions to compliant devices. Alert on sign-ins where the session's IP address or device changes soon after MFA.

Sources: CloudSEK; BleepingComputer

Okta analyzes infostealer dump with 44,791 unique JWTs, 1,843 tokens still valid at release

Okta published research on September 9, 2026 on a 7 GB infostealer dump posted to Telegram on August 2.

What happened: The dump held data from 5,871 infected machines. Okta identified 44,791 unique JWTs, including 555 likely related to AI-service authentication, plus 2,937 authentication-related JWEs. As of the dump's release, 1,843 JWTs and JWEs hadn't expired. Okta said unexpired session secrets could potentially be replayed to bypass credential-based authentication. The research didn't report a successful replay or a confirmed account takeover. Whether replay works depends on the service and on controls such as token binding or IP allowlisting. (Okta)

Why it matters: Infostealers take whatever sits on the endpoint, and tokens are part of that haul. Token lifetime sets how long a stolen secret stays useful. The AI-service tokens in the set show that the exposure now reaches newer tools that teams often adopt outside central identity management.

The defensive takeaway: Shorten token lifetimes where the service allows it, and bind tokens to a device or network where supported. After an infostealer infection, revoke sessions and rotate secrets, not just reset the password. Include AI-service accounts in your inventory of tokens and API keys.

Source: Okta

JeetBot Twitch extension forwarded OAuth tokens through operator-controlled proxies

The malicious Twitch browser extension JeetBot had roughly 30,500 store installations across Chrome and Firefox (an installation estimate, not a confirmed compromise count).

What happened: Socket found it captured account-scoped Twitch OAuth tokens and forwarded them in an &auth= query parameter through operator-controlled proxies. The reporting doesn't establish that the tokens were used for unauthorized activity. Firefox version 85.8.7 (September 16) and Chrome version 85.8.9 (reported September 25) stopped the forwarding. The operator disputed calling the extension malicious but acknowledged security and disclosure problems. (Socket)

The defensive takeaway: Audit installed browser extensions, and treat any token that appeared in a URL as exposed. Users of JeetBot should revoke the app's access to their Twitch account.

Source: Socket

Microsoft Entra begins auto-enabling passkeys ahead of SMS and voice MFA retirement

Microsoft Entra began auto-enabling passkeys on September 1, 2026 for public-cloud users already enabled for SMS or voice MFA in the Entra Authentication Methods Policy or legacy settings.

What happened: When these users next sign in and complete MFA, they are nudged to register a passkey. The nudge can typically be snoozed, and a temporary tenant opt-out is available through February 1, 2027. Microsoft-provided SMS and voice delivery retires on February 1, 2027 for most users, and on July 1, 2027 for Global Administrators and external users. Organizations with a legitimate need can continue SMS or voice through a supported telephony provider. That configuration option is scheduled for October 30, 2026.

Why it matters: The change moves the default away from phone-based factors, the type the BigBear 2.0 campaign above shows can be relayed. Tenants that do nothing will see registration prompts now and lose Microsoft-provided SMS and voice delivery in 2027.

The defensive takeaway: Inventory which users and service processes still rely on SMS or voice. Start passkey registration with administrators and external users, whose deadline is earliest. Decide before February 1, 2027 whether you need a telephony provider or can retire these methods entirely.

Source: Microsoft Learn

What this means for your team

Most of this month's cases come down to credentials that kept working after they should have stopped. Six steps your team can take to avoid similar problems:

1. Inventory non-human credentials. List API keys, service-account tokens, GitHub App private keys, and CI/CD secrets the way you list user accounts. Give each a named owner and a documented expiration or rotation plan. The Brevo and GitHub App cases both involved keys that nobody was tracking.
2. Scope and expire. Grant each key only the permissions the integration needs, and set an expiration wherever the provider supports one. Where it doesn't, schedule manual rotation.
3. Test revocation before you need it. For each provider, confirm what revoking a session, JWT, OAuth grant, or refresh token actually does. After an incident, run the revocation path end to end instead of relying on the documentation. Revoke sessions and rotate secrets, not just reset the password.
4. Close the OAuth and session gaps. Disable device-code flows for users who don't need them, and move administrators to passkeys or FIDO2 keys ahead of Microsoft's 2027 SMS and voice retirement. Where supported, bind sessions to devices.
5. Patch exposed identity infrastructure first. Cisco ISE, JFrog Artifactory, Cleo Harmony, and WSO2 issue or validate access for everything behind them. Treat their updates as a priority over routine patching.
6. Log enough to reconstruct an incident. Keep session and token logs detailed enough to show who authenticated, from where, and with which token. NIST IR 8587 is a usable checklist for this and the points above.

For related reading, see our guides on the secrets rotation lifecycle and hardcoded secrets.

Monthly cybersecurity news: Authentication under siege

August 2026’s incidents bypassed authentication entirely: confirmed exploits in N-able N-central and SharePoint, 9,300+ exposed AWS keys, and Mirage2FA hijacking sessions after MFA. Here’s what IT and security teams need to patch and audit first.

PassworkPasswork Team

Post-quantum password security: What changes and what to do

Grover’s algorithm barely dents a properly hashed password. Shor’s algorithm guts the RSA key exchange sitting next to it. Here’s the 3-layer audit that tells you which one is actually your problem.

PassworkPasswork Team

2026 IBM Cost of a Data Breach Report: The $6M AI threat no one’s fixing

Global breach costs hit record $4.99M in 2026, with detection taking 247 days. AI-driven attacks surge 56%, but the real crisis: defenders deploy AI everywhere except where attackers break in. 92% of AI-breached organizations had zero proper access controls.

PassworkAlex Muntyan