🔥 CyberForge CVE of the Day #042 🚨 CVE-2026-19117 — Delinea Secret Server FIDO2 Credential Registration Bypass Enables Unauthenticated Account Impersonation Today’s CyberForge specimen strikes directly at the boundary where a strong physical authenticator is bound to a human identity. Delinea has disclosed a Critical vulnerability in Secret Server On-Prem, its privileged access management vault. Under conditions that remain undisclosed, an attacker can register a FIDO2 credential they control against a target Secret Server account and then authenticate as that user. The attacker needs no existing Secret Server account, no prior privileges and no victim interaction. The cryptography can work perfectly. The catastrophic failure is that the attacker’s key has been trusted as belonging to somebody else. And when the affected application safeguards administrator passwords, service accounts, database credentials, private keys and access to downstream infrastructure, one corrupted identity binding can become far more than an ordinary application account takeover. 🔑 Key details: ⭐ Severity: Critical — CVSS v3.1: 9.8 📐 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 🧠 Weakness: CWE-290 — Authentication Bypass by Spoofing 🎯 Target: Delinea Secret Server On-Prem 💻 Platform: Windows 🔓 Authentication before exploitation: None 🌐 Attack vector: Network ⚙️ Attack complexity: Low 👆 User interaction: None ⚔️ Confirmed result: Authentication as the targeted Secret Server user 💥 Impact: High confidentiality, integrity and availability 🛡️ Preferred fix: Upgrade to Secret Server 12.2.7 or later 🧩 Branch fixes: 11.7.62, 11.8.2, 11.9.48, 12.0.23 and 12.1.3 ☁️ Cloud status: Secret Server Cloud is not listed as affected 🧪 Public PoC: None credibly identified during CyberForge research 🌍 Active exploitation: None publicly confirmed 📋 CISA KEV: Not listed as of 4 September 2026 📊 CISA SSVC: Exploitation none / Automatable yes / Technical impact total 📉 EPSS: 0.284% — 21st percentile at review time 🔎 Visual advisory: GHSA-frh3-mpfw-wxxq — currently an unreviewed GitHub mirror 🧬 What actually went wrong? FIDO2 is designed to provide phishing-resistant authentication using public-key cryptography and a physical authenticator. In Secret Server’s documented normal flow, an administrator enables FIDO2 for a user. After the normal password stage, that user completes a browser registration ceremony with their hardware key. The server stores the credential for the account and asks for the key on future logins. CVE-2026-19117 corrupts trust during that enrolment stage. Delinea says an attacker can, under “specific conditions,” register an attacker-controlled FIDO2 credential against a target account and subsequently authenticate as that user. This does not demonstrate a cryptographic break in FIDO2. The authenticator may produce completely valid signatures. The problem is that Secret Server has associated its public key with the wrong identity. Picture an extremely secure key cabinet with a named slot for every employee. The cabinet correctly validates whichever key occupies a slot—but a registration flaw lets a stranger place their own key into somebody else’s slot. The lock remains strong. The ownership record is wrong. That distinction matters because defenders should not respond by abandoning hardware security keys. They should protect the entire authenticator lifecycle: 🔹 Initial enrolment 🔹 Registration callbacks and challenges 🔹 Replacement and recovery 🔹 Help-desk resets 🔹 Identity-to-key binding 🔹 Alerts for authentication-method changes 🔹 Independent approval for privileged users ⚔️ The confirmed attack chain: 1️⃣ An attacker gains network access to a vulnerable Secret Server On-Prem interface. 2️⃣ They identify or select a target Secret Server account. 3️⃣ They satisfy Delinea’s undisclosed conditions in the FIDO2 registration workflow. 4️⃣ The vulnerable application accepts an attacker-controlled FIDO2 credential and binds it to the target identity. 5️⃣ The attacker uses that registration to authenticate as the target user. 6️⃣ Secret Server applies the target user’s existing roles, permissions and secret access to the attacker’s session. 7️⃣ The intruder may then view, check out, launch, alter or use whichever secrets and functions that identity is authorised to access. Steps 1–6 reflect the public vulnerability at a safe, high level. Step 7 is permission-dependent. Delinea has not disclosed the vulnerable endpoint, request body, target-account state, identifier, callback token or exact meaning of “specific conditions.” There is no trustworthy public request recipe to reproduce. CyberForge will not manufacture one. ⚠️ What the 9.8 score does—and does not—tell us The vendor vector records: 🌐 Network reachability ⚙️ Low attack complexity 🔓 No privileges required 👆 No user interaction 🎯 Unchanged scope 💥 High confidentiality, integrity and availability impact “Network” does not automatically mean “Internet-wide.” An attacker still needs a route to the vulnerable on-premises interface. That access might come from direct public exposure, a remote-access environment, an over-permissive partner path, a user network or a host already compromised inside the organisation. Likewise, “authenticate as the target user” does not mean every attacker automatically becomes a Secret Server administrator. The acquired authority is governed by the targeted identity’s permissions. The score captures the vulnerability’s technical maximum. Local exposure and blast radius still depend on architecture, account state and vault permissions. 💥 Why a PAM vault makes this especially dangerous. Secret Server is designed to centralise and control privileged identities. Depending on the organisation, it may contain or broker access to: 🔹 Active Directory domain-administrator accounts 🔹 Windows local-administrator credentials 🔹 Unix and Linux root accounts 🔹 Database administrator accounts 🔹 Cloud administrative credentials 🔹 Network-device passwords 🔹 Service and application accounts 🔹 API credentials 🔹 Private keys and certificates 🔹 Sensitive files and recovery material 🔹 RDP, SSH and other privileged launchers If the impersonated user has narrowly scoped access, the initial damage may be contained to a small secret set. If the account is a vault administrator, approver, user owner or highly privileged operator, the potential blast radius becomes much larger. An attacker could potentially use exposed secrets against downstream servers, databases, cloud tenants and network equipment. Those are conditional follow-on risks—not confirmed effects of the CVE itself. The public evidence does not establish: ❌ Direct remote code execution on the Secret Server host ❌ Automatic Secret Server administrator access ❌ Universal access to every secret in the vault ❌ Compromise of Secret Server Cloud ❌ A general break of the FIDO2 standard ❌ A confirmed threat campaign or known victim 📦 The complete affected-version matrix Delinea lists these vulnerable ranges: 🔴 10.6.0 through 11.7.61 ✅ Fixed in 11.7.62 🔴 11.8.0 through 11.8.1 ✅ Fixed in 11.8.2 🔴 11.9.0 through 11.9.47 ✅ Fixed in 11.9.48 🔴 12.0.0 through 12.0.22 ✅ Fixed in 12.0.23 🔴 12.1.0 through 12.1.2 ✅ Fixed in 12.1.3 ⭐ Preferred destination: Secret Server 12.2.7 or later Delinea tells customers on versions before 11.7 to move to a supported release. The formal affected matrix begins at 10.6.0, so CyberForge is not inventing a vulnerability status for builds older than 10.6. Unsupported installations should be treated as urgent migration cases and confirmed directly with Delinea Support. The advisory does not separately declare a vulnerable 12.2.0–12.2.6 range. Do not infer the existence or status of those builds solely from the 12.2.7 version number. The safe conclusion is to install an explicitly fixed branch release or 12.2.7+. 🕰️ The quiet pre-disclosure patch timeline This vulnerability has an excellent coordinated-disclosure wrinkle. Delinea began shipping fixes weeks before the CVE became public: 📅 11 August 2026 — Secret Server 12.1.3 and 12.0.23 released 📅 17 August 2026 — Secret Server 11.9.48 released 📅 20 August 2026 — Secret Server 11.8.2 and 11.7.62 released 📅 28 August 2026 — Secret Server 12.2.7 released 📅 2 September 2026 — CVE-2026-19117 publicly disclosed The branch release notes explicitly say the CVE was withheld at release time to give customers an opportunity to update. That provided a valuable head start—but it also means organisations cannot use the CVE publication date alone as the beginning of their investigation window. Any system that remained vulnerable after the relevant fixed release became available deserves review. 🔬 What the patch notes reveal: The 12.2.7 release notes describe FIDO2 registration hardening in the same repaired product area: 🔹 Stronger validation in the FIDO2 two-factor registration callback 🔹 A corrected challenge comparison 🔹 Adjusted one-time registration-key lifetime 🔹 Corrected failed-attempt accounting and logging Those details illuminate the trust boundary Delinea strengthened. However, the vendor does not explicitly publish a complete root-cause analysis mapping every sub-change to CVE-2026-19117. They must not be transformed into an invented exploit recipe. 🕵️ The unusually useful audit trail: Delinea’s own FIDO2 documentation gives defenders a rare advantage. When a device is registered, Secret Server records the following in the user’s audit log: 🔍 The FIDO2 credential 🔍 The FIDO2 public-key JSON 🔍 The FIDO2 counter Each successful FIDO2 authentication updates the counter and produces another audit entry. Only one FIDO2 device can be registered to a user at a time. That creates several strong hunting pivots: 🔎 A privileged user receives a new FIDO2 registration without a matching help-desk ticket or hardware-key assignment 🔎 A dormant or rarely interactive account suddenly registers a key 🔎 Registration is followed immediately by authentication from a new IP, browser or network 🔎 Counter activity appears while the legitimate user confirms they were inactive 🔎 Failed registration events precede a successful binding 🔎 A legitimate user reports that their expected hardware key no longer works 🔎 One source address interacts with several target accounts The last key-failure scenario is an investigative clue, not proof. The vendor does not say whether exploitation always replaces an existing device or only operates during a vacant/pending state. 🛡️ Defender hunting guide: 1️⃣ Inventory the complete estate Find every primary node, web node, disaster-recovery instance, non-production clone and restored snapshot. Record the version actually serving traffic—not merely the installer package staged on disk. 2️⃣ Map reachability Determine whether the Secret Server interface can be reached from: 🔹 The public Internet 🔹 Remote-access networks 🔹 User or server VLANs 🔹 Partner networks 🔹 Development and test environments 🔹 Compromised internal workloads Review the controls that truly enforce access, including reverse proxies, VPNs, identity-aware gateways, WAFs and allowlists. 3️⃣ Inspect FIDO2 state Validate registered devices for administrators, approvers, user owners and users with broad secret access against authoritative key-assignment records. Search user audit logs for unexpected credential/public-key registration and counter changes. 4️⃣ Correlate surrounding telemetry Compare registration and authentication times with: 🔍 Secret Server authentication audits 🔍 Secret Server.log 🔍 IIS access logs 🔍 Reverse-proxy and WAF records 🔍 VPN and identity-provider telemetry 🔍 Source IP, forwarded IP and user-agent changes Delinea has not published the vulnerable endpoint, so there is no honest universal URL or payload signature to hunt yet. 5️⃣ Trace everything the identity touched Use Secret Server’s User Audit report and secret-level audits to examine: 🔍 Secrets viewed, checked out, launched or exported 🔍 Permission and folder changes 🔍 Role or group assignments 🔍 Approval and sharing activity 🔍 Password-rotation changes 🔍 New tokens, SDK clients or integrations 🔍 Administrative and logging configuration changes 🔍 Remote sessions initiated through vaulted credentials 6️⃣ Protect the evidence Forward audit events away from the vault using secure syslog or CEF where available. Keep copies of application, IIS, proxy and authentication logs in protected storage with reliable timestamps. When the security control itself is under investigation, off-box evidence becomes especially valuable. 🚑 Incident-response sequence: If an unexplained FIDO2 registration is discovered: 1️⃣ Preserve the relevant logs and user-audit records. 2️⃣ Restrict or isolate the vulnerable interface while maintaining evidence. 3️⃣ Upgrade to 12.2.7+ or the fixed release for the deployed branch. 4️⃣ Verify every active node and replica is genuinely running the repaired build. 5️⃣ Use Reset Two-Factor Authentication for suspect accounts. 6️⃣ Reset other authentication factors and account passwords where appropriate. 7️⃣ Revoke active sessions, tokens and persistent access. 8️⃣ Identify every secret the impersonated account could access and every secret it actually touched. 9️⃣ Rotate credentials whose exposure cannot be ruled out. 🔟 Investigate the downstream systems where those credentials are valid. 1️⃣1️⃣ Revert unauthorised roles, permissions, policies, integrations and configuration changes. 1️⃣2️⃣ Contact Delinea Support for endpoint-specific indicators and backend validation not available publicly. ⚠️ The disabling trap: This is perhaps the most important operational detail in the entire case. Delinea explicitly documents that disabling FIDO2 does not remove the stored device registration. If FIDO2 is later re-enabled, the already registered device can be used again without enrolment. Administrators must use Reset Two-Factor Authentication to unregister the device. So the correct response is not: ❌ Disable FIDO2 and assume the attacker’s key has vanished It is: ✅ Patch the vulnerable software ✅ Reset the suspect FIDO2 registration ✅ Re-enrol the legitimate user through a trusted process ✅ Revoke sessions and other authentication material ✅ Review and rotate exposed secrets 🌍 The exploitation picture: At the 4 September review point, CyberForge identified: 🟢 A vendor-confirmed Critical vulnerability 🟢 Exact affected ranges and patched branch releases 🟢 Strong user-audit artefacts for investigation 🟡 No credible public executable PoC 🟡 No confirmed exploitation in the wild 🟡 No CISA KEV listing 🟡 An early EPSS estimate of 0.284% CISA’s enrichment recorded exploitation as none, automatable as yes and technical impact as total. Those yellow items describe the maturity of public evidence—not technical safety. The CVE was only two days old when this analysis was completed. EPSS can change rapidly, exploit research may emerge later, and successful impersonation can resemble legitimate user activity. Waiting for a public exploit script or KEV addition would surrender the advantage created by Delinea’s already available patches. 🔥 CyberForge verdict: CVE-2026-19117 is an excellent example of why authentication security cannot begin and end at the login prompt. FIDO2 remains a powerful phishing-resistant standard. But a flawless signature cannot rescue a system that enrolled the attacker’s key under the victim’s name. For an ordinary application, that is a severe account takeover. For a privileged access vault, it may become the first step toward domain, cloud, database, server or network compromise—depending entirely on the targeted user’s authorised reach. The accurate headline is: 🔥 Critical unauthenticated FIDO2 credential-registration bypass leading to target-account impersonation It is not: ❌ FIDO2 cryptography broken ❌ Instant universal vault takeover ❌ Confirmed server-side RCE Patch every on-premises instance, validate every privileged authenticator, preserve the enrolment audit trail, and rotate downstream secrets wherever exposure cannot be confidently excluded. The lock may still be magnificent. But first, make absolutely certain whose key is inside it. 🔗 Full visual advisory: https://github.com/advisories/GHSA-frh3-mpfw-wxxq 🔗 Full vulnerability details: https://nvd.nist.gov/vuln/detail/CVE-2026-19117 #CyberSecurity #CVE #CyberForge #Delinea #SecretServer #FIDO2 #WebAuthn #PAM #IdentitySecurity #AuthenticationBypass #AccountTakeover #BlueTeam #ThreatHunting #IncidentResponse #PatchNow
Post summary
The advisory highlights a critical FIDO2 credential‑registration bypass in Delinea Secret Server, provides comprehensive patch details and mitigation guidance, and confirms no public PoC or active exploitation.
