- NIST's database says Umbraco CMS before 17.7.2 and 18.2.2 lets unauthenticated attackers register their own OAuth redirect addresses by poisoning the Host header.
- The record says the attack also needs a signed-in user to receive an attacker's link. It then ends in a hijacked back-office session and code execution through Razor templates.
- Find every Umbraco site you run, including agency-managed ones. 17.x sites need 17.7.2 or later, and 18.x sites need 18.2.2 or later.
A site's name is a claim, not a fact
Every web request carries a line saying which site the visitor wants. That line is called the Host header. The sender writes it, so the sender can write anything. CVE-2026-117553 involves attackers poisoning that line.
The general lesson is that a name arriving with a request is only a claim. It becomes trustworthy when something checks it. That is the publication's reading of the pattern. The record does not say which check is missing here.
What the record says
NIST's National Vulnerability Database published the entry on October 27, 2026. It describes Umbraco CMS versions earlier than 17.7.2 and 18.2.2. In those versions, someone with no login can get the site to accept OAuth redirect addresses of their own choosing, by poisoning the Host header. NVD labels this an authentication bypass.
Some background helps. OAuth is a standard sign-in handshake. A redirect URI is the address where the server sends a sign-in code once a user approves. That is general OAuth knowledge, not a finding from the record.
The record says attackers register their own address. It then says they capture codes through links that use response_mode=form_post. It does not explain how the registered address and the captured codes connect.
How the attack works, as far as the record goes
The record describes a chain of steps. First, the attacker poisons the Host header to register a redirect address. No login is needed for this step.
Next, the attacker sends a signed-in user an authorization link that uses response_mode=form_post. The record says this is how the codes are captured. The attacker then redeems a captured code using HTTP Basic client credentials. That is a standard way for an application to prove its identity to a server.
The record says the result is a hijacked back-office session, followed by code execution through Razor templates. Razor is a template language used to build pages. The record gives no detail on how this last step works or what it requires.
The sources also do not say why Umbraco uses the Host header when registering these addresses, or what the fix changes. NVD lists the project's advisory, GHSA-rpv9-qp4c-g469, and a commit. It also points to lines 74 to 112 of BackOfficeAuthorizationInitializationMiddleware.cs in release 18.2.1. Your engineers can read those for the exact cause.
How hard is the attack?
VulnCheck, which scored the entry, gives it 7.5 (High) under CVSS 3.1 and 7.7 (High) under CVSS 4.0. Both scores rate the impact on confidentiality, integrity and availability as high.
The two scores disagree on difficulty. The 3.1 vector rates attack complexity as high and user interaction as required. The 4.0 vector rates attack complexity as low, with an attack requirement present (AT:P), and also records user interaction.
Read together, both say a signed-in person has to be reached with a link. They do not agree on how much else must line up. The NVD record says nothing about attacks happening in the wild.
That condition is a thin comfort. The person in the middle is a colleague with a back-office login who opens a link. That is an ordinary act.
What leaders should ask this week
Ask your team for a list of every Umbraco site you run. Include staging copies and sites an agency manages for you. These are easy to miss.
Ask which versions they run. Per the record, versions before 17.7.2 and 18.2.2 are affected. 17.x sites need 17.7.2 or later, and 18.x sites need 18.2.2 or later. Moving to those releases is the fix the record points to.
Ask whether the back office can be reached from the public internet. Ask who holds a login and whether each person still needs one. Fewer signed-in users means fewer people who can be sent a link.
Ask whether anything in front of the site limits the host names it will answer to. Ask for the answer in writing.
If the cause is what the Host-header pattern suggests, the habit behind it is a common one. A request that describes itself is a claim. Make sure someone checks it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
