Delinea Secret Server login bypass: why 12.2.7 won't save you from this 9.9
Delinea rescored a Secret Server flaw to CVSS 9.9: no password, no account. Version 12.2.7 is affected too. Who needs 12.3.000002, how to upgrade, and what to check in your logs.
part 30 of 30 · Platform releases, explained from scratchthe ideaNo password, just a PIN: fence the login, go to 12.3.000002, read the logs.
after reading, you can- Work out whether your Secret Server is exposed, even if you upgraded to 12.2.7 for the September flaws
- Plan the move to 12.3.000002, and spot what can catch you out once it's done
- Check audit history and mail logs for PIN activity that nobody on your team can explain
Delinea has published three new flaws in self-hosted Secret Server, and on November 5 it raised the worst one to a CVSSdefinitionHow bad a security flaw is, from 0 to 10. Version 4 also tells you if an attacker needs a login, or if special conditions have to be in place. score of 9.9. If you run Secret Server on your own servers at 12.2.7 or earlier, upgrade to 12.3.000002 now, and fence off the login page until you have. That includes anyone who moved to 12.2.7 for the September flaws.
Your password vault may let someone in who doesn't know a password. Upgrade it now.
Secret Server is where IT teams keep their most powerful passwords: domain admins, database owners, service accounts. To get in, you normally type a password and then prove who you are a second way, often with a short code. Delinea says that on older self-hosted versions, someone could trigger that code for any account without logging in, skip the password step and sign in with the second factor alone. We found no public report of attacks so far. But the way in looks simple, and what's behind it is the keys to the rest of the company, so this one shouldn't wait for the monthly patch window.
Think of an office with two checks. A guard looks at your badge, then your phone gets a code for the inner door. This flaw is a side corridor nobody meant to build: a stranger skips the guard, walks up to that door, asks for a code in any employee's name and keeps trying.
- Teams running Secret Server on-prem
- PAM and identity admins
- Security and incident response
- Owners whose MSP runs the vault
- Anyone who just moved to 12.2.7
Why it matters to you
Whoever signs in to the vault as an admin can usually read the domain admin password, and from there reach almost anything else on the network. That's why a login bypass on a PAM vault is worse than the same bug on most other apps. The score tells you how Delinea sees it now: reachable over the network, easy to pull off, no account needed and no help from a user.
The rescoredefinitionWhen a vendor changes the severity of a flaw after publishing it. Tools and tickets that copied the first number can stay out of date. is the part most people will miss. When these CVEs first went public on October 30, the worst was 8.7 and the record said an attacker already needed high privileges, which reads like an insider problem you can schedule for later. Six days later Delinea changed that to no privileges at all, gave the flaw a blunter title and rewrote its description. If your scanner or ticket copied the first record, it may still show 8.7, and the ticket may be sitting in the wrong queue.
On attacks, the picture is calm for now, with one caveat. The CISA catalog of known exploited flaws doesn't list any of the three (we checked catalog 2026.11.04), Delinea's advisory doesn't mention attacks, and we found no public exploit code. CISA's own note on the record says exploitation none and automatable no, but CISA wrote that on October 30, before the rescore. Secret Server also has some history here: after a 2024 login bypass, a security engineer's public write-up included a proof-of-concept exploit. So don't plan around this staying quiet.
-
01 The attacker reaches the login page
Going by the score, reaching Secret Server over the network is enough. They don't need an account, and nobody on your side has to click a thing.
-
02 A PIN gets generated for any account
The attacker picks an account, any account. The CVE record says a two-factor pin code could be generated for it with no prior login.
-
03 The password step gets skipped
Normally the password comes first. Here the attacker can bypass that step and go straight to the second factor, so a strong password doesn't help.
-
04 They get the second factor right
Delinea's title for the flaw names brute force, so expect repeated guessing here. It hasn't said how many tries that takes.
-
05 They're in as that user
The attacker now has whatever that person can see. Depending on roles and permissions, that can include stored passwords, launchers and settings.
For engineers, a few details help. The weakness class is CWE-288, an authentication bypass through an alternate path or channel, which MITRE describes as a product that requires authentication but has another route that doesn't. Delinea's advisory text is thinner than its CVE record: the advisory's title names PIN reset and brute force, but its description only says a user could skip the first step by negotiating the second factordefinitionWhat you show after your password, usually an emailed code or a security key. In this flaw it's the only step the attacker has to pass.. The record adds the unauthenticated PIN generation. Neither says which second factor methods are in play.
Here's our own reading, so treat it as that. Secret Server uses the words "pin code" for its email second factor, where it mails a six-digit code. That makes email PIN users the obvious place to look first, but Delinea hasn't confirmed it. Don't assume you're safe because your admins use something else. Lockout is unclear too: Delinea's docs say each wrong PIN counts toward the Maximum Login Failures limit in a normal sign-in, but nobody has said whether this path respects that counter.
What Delinea fixed, and the other two CVEs
All three flaws share one fix, and there's no hotfix or workaround listed for any of them. The advisory's only resolution is to upgrade to on-prem 12.3.1. Older hotfix builds from the September round don't help, since every version up to and including 12.2.7 is listed as affected.
The three CVEs, and what they do
CVE-2026-115829, CVSS v4 9.9. Someone with no login could get a two-factor PIN generated for any account, skip the first step and sign in with the second factor. That's the one to worry about first.
CVE-2026-115828. Secret Server didn't always validate the PIN or biometric check on a FIDO2 device. CVSS v4 9.4, but the score says the attack is harder and needs certain conditions to be present.
CVE-2026-115830, CVSS v4 8.7. Under certain conditions, a user could submit an unsigned JWT and get cloudadmin permissions back. Its score still says high privileges are needed. Our reading: think insider or stolen admin account.
| CVE | Score on Oct 30 | Score on Nov 5 | Privileges the score assumes now |
|---|---|---|---|
| CVE-2026-115829 | 8.7 | 9.9 | None |
| CVE-2026-115828 | 5.1 | 9.4 | None, with harder conditions |
| CVE-2026-115830 | 8.7 | 8.7 | High |
A word on the 115828 jump, from 5.1 to 9.4. Our reading is that it's the less urgent of the two critical scores, because the score says the attack is harder and depends on specific conditions. A FIDO2definitionWhat sits behind hardware security keys like a YubiKey. You touch the key, and it can ask for its own PIN or your fingerprint first. key is meant to prove someone is holding it and knows its PIN or has the right fingerprint, so if that check is skipped, a lost or stolen key is worth more than it should be. That last step is our reading of the description. Delinea hasn't spelled it out.
| Your version | Status | What to do |
|---|---|---|
| 12.3.000002 | Fixed | Stay here, or move to a later build when one ships. |
| 12.3.000001 (12.3.1) | Fixed | Move to .000002 if anyone signs in with Windows authentication and two-factor. The first build sent them back to the login page. |
| 12.2.7 | Affected | Upgrade. This was the safe target for the September CVEs, and it isn't any more. |
| 12.1.3, 12.0.23, 11.9.48, 11.8.2, 11.7.62 hotfixes | Affected | Upgrade. These also stay open to the September SAML or padding oracle flaws. |
| Below 11.9.000025 | Affected | Plan a step upgrade through 11.9.000006, and confirm the path with Delinea support. |
| Secret Server Cloud | Not listed | Nothing to install. Delinea lists all three for the on-prem product only. |
How it unfolded
- Aug 28, 202612.2.000007 released
This closed the September flaws, so it looked like a safe place to stop. It's also the newest build these new flaws affect.
- Oct 21, 202612.3.000001 released
The fix is out, but the notes don't name any CVE, so few people would've known to rush.
- Oct 23, 202612.3.000002 maintenance build
Fixes the sign-in loop for Windows authentication users with two-factor. If that's your setup, skip straight to this build.
- Oct 30, 2026Three CVEs published
The worst gets an 8.7 and reads as if it needs high privileges, so it wouldn't have looked like a rush job.
- Nov 2, 2026Notice on Delinea's trust portal
The notice still calls it a "partial login bypass". That name won't set off many alarms.
- Nov 5, 2026Scores and wording change
CVE-2026-115829 jumps to 9.9 with no privileges needed and CVE-2026-115828 to 9.4. Older tickets may now be wrong.
What to do now
What to do now, by who you are
- Ask IT or your managed service provider: do we run Delinea Secret Server, and is it their cloud or our own servers?
- If it's your own servers, get the exact version number in writing. Anything at 12.2.7 or below needs the upgrade.
- Ask for an upgrade date this week, and for who approves the emergency change.
- Read the version off every instance, including disaster recovery replicas and test servers holding real secrets.
- Block the login page from the internet today, and let only staff networks or VPN reach it until the upgrade is done.
- Back up the database and application folder first. Keep encryption.config unencrypted in that backup, then upgrade to 12.3.000002.
- Bring engines and the Protocol Handler up to the 12.3 versions, then test every sign-in method you use.
- Any ticket raised before November 5 probably has the wrong severity. Re-open it and bump it to match the 9.9.
- Pull user audit history for admins: look for LOGIN FAILED INVALID TWOFACTOR runs and ACCOUNTLOCKEDFAILEDATTEMPTS events.
- Compare mail server logs for "[SecretServer] Pin Code" messages against real sign-ins, since sends aren't audited.
- Ask admins whether they've had PIN emails they didn't ask for. It's a cheap question and a useful signal.
Those email checks come from how Delinea documents the normal flow, and they're the cheapest early warning you have. A user with email two-factor who signs in fully gets two LOGIN SUCCESS events in a row, one per phase. A PIN that gets emailed leaves no audit event, only the attempt to use it does, so your SMTP logs are where you'd see the send. Nobody has confirmed that this flaw's path sends email at all. A lone success with no password phase in front of it deserves a question. That pattern is our inference and Delinea hasn't published indicators, so a clean result doesn't prove nothing happened.
# example output. Event names come from Delinea's email 2FA docs; field names vary by SIEM, so match them to yours # 1. Wrong PINs on one account, or across many accounts from one address source = secret-server-audit and action = "LOGIN FAILED INVALID TWOFACTOR" | count by user, ip, 10m # 2. Accounts locked by failures. Look hard at admins nobody says were locked out source = secret-server-audit and action = "ACCOUNTLOCKEDFAILEDATTEMPTS" | table time user # 3. PIN emails sent. Check them against real sign-ins, since only the mail server sees a send source = smtp and subject = "[SecretServer] Pin Code" | table time recipient # any send with no matching sign-in?
The emergency upgrade order
- 01Fence first
Restrict the login page to staff networks or VPN at the firewall or load balancer. Delinea doesn't list this as a mitigation, but the score assumes network reach, so it takes most outsiders off the board while you prepare.
- 02Find every instance
Production, DR replicas, test and that old pilot server nobody turned off. Read the version from each one, because the change ticket may be wrong.
- 03Back up the right things
Save the Secret Server database and the application folder on every web node, with unencrypted copies of encryption.config and database.config. Delinea's checklist says not to proceed without them and suggests planning about two hours.
- 04Step if you have to
Delinea's 12.2.000007 notes say versions before 11.9.000025 must go to 11.9.000006 first, and that offline installs skipping it fail an integrity check. The 12.3 notes don't repeat this, so confirm the path with support if you're that far back.
- 05Upgrade to 12.3.000002
Don't stop at 12.2.7 or at 12.3.000001. Then bring the engines, session-recording agent and Protocol Handler up to the versions listed for 12.3.
- 06Test what could break
Sign in with each method you use, launch a recorded session, run a rotation and run your API scripts. Then look at your first domain sync and any large AD discovery scan.
- 07Then hunt
With the hole closed, go through the audit and mail logs. The fix came out October 21 and the CVE records came out October 30, but older exposure can't be ruled out, so look back as far as your logs go.
Harden so the next one hurts less
This is the second round of critical Secret Server login flaws in about two months. September's FIDO2 and SAML bypasses got fixed in 12.2.7, and here we are telling you 12.2.7 isn't enough. So the durable fix is a vault that can take an emergency upgrade quickly, with a login page few people can reach.
Before: the vault's login answers anyone
Anyone who can load the login page can start this attack, and Delinea's docs say email PIN sends have no audit event in the vault.
After: patched, fenced and watched
Only staff networks reach the login, and failed second factors and PIN emails land somewhere a person looks.
- Remote staff asked for internet access once, and the login has been open ever since
- Someone set the severity from the first CVE record, and nobody looked again
- Vault upgrades wait for the normal quarterly change window
- Nobody reads PIN emails or failed second factors until an auditor asks for them
- Login reachable only through VPN or zero trust access
- Someone re-reads the live CVE record for each open vault flaw until its ticket closes
- A rehearsed emergency upgrade path, with backups and rollback already written down
- Second-factor failures and lockouts alert, and someone owns the alert
Also look at how many people hold admin roles in the vault, because this flaw lets an attacker choose whose account to target. A short list of named admins, with break-glass accounts sealed and watched, makes the worst case smaller. It also makes the audit review possible in an afternoon.
If you've been breached
If you find a sign-in nobody can explain
Work through these in order. Save the evidence before you change anything, and don't rotate passwords until the attacker's access is gone, or they may simply read the new ones.
- 01Containfirst hour
- Cut the login page off from everything except a small admin network at the firewall.
- Back up the database, application folder with encryption.config, audit data, and IIS and SMTP logs before changing anything.
- Disable the affected Secret Server accounts, but leave them in place so the audit trail stays.
- Open a priority case with Delinea support and cite the CVE numbers.
- 02Investigatefirst days
- Go through the audit history of each affected account and list every secret viewed, checked out or launched, with times.
- Trace launched RDP and SSH sessions to the servers they reached, and check those for new accounts or tasks.
- Look for changes nobody asked for: new users, changed roles, API settings and folder permissions.
- Write down every credential those accounts could reach. That list is your worst case.
- 03Removeday 1 to 2
- Upgrade to 12.3.000002 before letting anyone back in.
- Run Reset Two-Factor Authentication on affected users. Just disabling FIDO2 won't do, since Delinea says that keeps the device registered.
- Remove any accounts, roles or settings the attacker added. Check twice, since one leftover admin role undoes the rest.
- 04Recoverweek 1
- Rotate every credential on the worst-case list, starting with domain admins and service accounts.
- Rebuild any server you can't confidently clean, then bring users back in small groups.
- Watch logs closely for the following weeks in case the attacker kept another way in.
- 05Report and learnas required
- Bring in legal counsel and your cyber insurer early. They'll help decide who has to be told and by when.
- Tell regulators and clients if your obligations say you must. Write down what you knew and when, because someone will ask.
- Write up what actually helped and what didn't, the fence and logs included. Then fix the gaps while people still care.
What this could look like
Three typical setups
- the setup
- A regional insurer upgraded its on-prem vault to 12.2.7 to close the earlier flaws, then closed the ticket. Remote admins still reach the login over the open internet.
- what happens
- The October 30 record looked like a high-privilege problem, so the new ticket went in the next quarterly window. After November 5 the same flaw needs no login at all, and nothing prompted anyone to look again.
- what to do
- Fence the login today, move to 12.3.000002 this week and raise the ticket's severity. Then check admin audit history and mail logs.
- the setup
- A manufacturer took 12.3.000001 as soon as it came out, for other reasons. Staff use Windows authentication and Duo, and now the help desk keeps hearing about login loops.
- what happens
- These three flaws are fixed on this build. The loop is the separate bug Delinea fixed two days later, and until it's gone people may push for risky shortcuts such as turning off two-factor.
- what to do
- Move to 12.3.000002 and keep two-factor on. Run the log review anyway, covering the time before the upgrade.
- the setup
- A 60-person accounting firm has its passwords in Secret Server, run by a managed service provider. The owner doesn't know the version or where it's hosted.
- what happens
- If it's the provider's own install at 12.2.7 or below, this applies, and one breached vault could affect every client on it. If it's Delinea's cloud service, there's nothing to install.
- what to do
- Email the provider today. Ask for the version in writing, the upgrade date and whether they've reviewed sign-ins to your accounts.
How Cohash helps
We implement and upgrade Delinea Secret Server, including the step upgrades, distributed engines and launchers that make these jobs slow. If you want a second pair of hands for the move to 12.3.000002, or a review of who can reach what in your vault afterwards, start with our Delinea page, look at Delinea engineers you can bring in, or take the free assessment to see where your privileged access stands.
What to take from this
- 01
Self-hosted Secret Server at 12.2.7 or earlier needs 12.3.000002. No hotfix or workaround is listed.
- 02
Check the live CVE record. Delinea moved this flaw from 8.7 to 9.9 six days after publishing it, so old tickets may be wrong.
- 03
Fence the login page today. It costs little and it doesn't depend on the change window.
- 04
Delinea's docs say email PIN sends have no audit event, so pull mail server logs alongside user audit history.
- 05
We found no public reports of attacks yet, and a clean log review doesn't prove nothing happened.
01Am I affected by CVE-2026-115829?
If you run Secret Server on your own servers at 12.2.7 or earlier, yes. That includes the September hotfix builds. Version 12.3.1 and later are fixed, and we'd take 12.3.000002.
02We upgraded to 12.2.7 last month. Do we have to upgrade again?
Yes. That upgrade closed the September flaws, but all three of these list 12.2.7 as affected. There's no hotfix for 12.2.7 in the advisory, so the way out is 12.3.
03Is 12.3.1 the same as 12.3.000001?
As far as we can tell, yes. The advisory says 12.3.1 and links the 12.3.000001 release notes. Go one further to 12.3.000002, because the first build sent Windows authentication users with two-factor back to the login page.
04We're on Secret Server Cloud. Do we have to do anything?
There's nothing to install. Delinea lists all three for the on-prem product, and it changed the CVE records on November 5 to say so. If you still have an old on-prem server from before the move, check that it's really off.
05Has anyone exploited this?
Nothing public so far. It isn't in CISA's catalog of known exploited flaws (catalog 2026.11.04), Delinea's advisory doesn't mention attacks and we found no public exploit code. CISA's note saying exploitation none dates from before the rescore, so keep checking.
06Why did the score jump from 8.7 to 9.9?
Delinea changed the record to say no privileges are needed and that the attack isn't complex. It also renamed the flaw and rewrote the description. Delinea hasn't published why it changed its assessment.
07Can we switch something off instead of upgrading?
The advisory lists no workaround. Limiting who can reach the login page cuts the risk while you prepare, but it's a stopgap of ours and it doesn't fix the flaw. Staff on those networks could still reach it.
08How long will the upgrade take?
Delinea's checklist suggests planning a change window of about two hours, and says your method, size and complexity determine the actual disruption to users. Older versions may need a step upgrade first, so read your version before you promise anyone a time.
Three questions, about a minute
Pick an answer and we'll tell you if it's right, and why it is or isn't. The score stays in this browser.
-
Q1Your on-prem vault moved to 12.2.7 last month to fix the September CVEs. What's your status for CVE-2026-115829?
show the answer
B. Affected, and you need 12.3.1 or later Delinea lists 12.2.7 or earlier as affected, and the only resolution is 12.3.1. The September upgrade doesn't cover these flaws, so the target is now 12.3.000002.
-
Q2Your October 31 ticket says 8.7, high privileges needed, and it's parked in the quarterly window. What now?
show the answer
C. Check the live record and treat it as urgent Delinea changed the record on November 5 to 9.9 with no privileges required. Severity copied from the first record is out of date, and waiting for attacks to appear means reacting late.
-
Q3You want to know whether anyone triggered PIN emails to your admins. Where do you look?
show the answer
B. The mail server logs, alongside the audit history Delinea's docs say sends have no audit event, and only PIN use is recorded. Mail server logs show the send, and the user audit history shows what happened next.