CVE-2026-32610, modified by CISA on Wednesday and assigned a CVSS base score of 9.3, is the kind of vulnerability that makes security engineers wince and line-of-business developers throw up their hands. The open-source system monitor Glances shipped a default CORS configuration that set Access-Control-Allow-Origin to * while simultaneously setting Access-Control-Allow-Credentials to true. Any website could make authenticated requests to a Glances server from a user’s browser. Configuration secrets, command-line arguments, system telemetry — all available to any attacker who could get a victim to visit a malicious page.
The fix, released in Glances 4.5.2, changes the default to disable credentials when origins are unrestricted. The patch is four lines.
Every postmortem thread on Hacker News and every infosec hot-take account will tell you the same thing: developers don’t understand CORS. They never have. The 2019 Chris Foster post that resurfaces whenever a CORS CVE drops has been bookmarked so many times it might as well be canonical scripture. “Read the spec,” the replies say. “It’s not that complicated.”
Here’s the thing: the replies are wrong. Not about the spec being readable. About the problem being a knowledge gap. The problem is structural. The CORS specification, as it exists in 2026, was designed for a web of documents and widgets, not a web of APIs, microservices, and single-page applications that embed third-party authentication flows into every request path. And the tooling that sits between developers and the browser’s security model has quietly made correct configuration a game of Jenga.
The Spec Is Coherent. The Ecosystem Is a Minefield.
The core rule of CORS is simple enough to fit on a sticky note: when credentials are included, Access-Control-Allow-Origin must be an exact, specific origin — never *. Every browser enforces this. Violate it, and the browser blocks the request. The MDN documentation states it plainly. The Fetch spec is unambiguous.
So how did Glances — a project with over 25,000 GitHub stars, maintained by competent developers — ship a configuration that violates the single most well-documented rule in cross-origin security?
Because the ecosystem told them it was fine.
Glances didn’t hand-roll a CORS header. It used a Python web framework’s CORS middleware, the kind that ships with a allow_all_origins=True convenience parameter. Framework authors, incentivized to reduce the number of Stack Overflow questions about “why won’t my API respond to my frontend,” have spent a decade adding progressively more permissive defaults. Express.js cors() with no arguments enables *. Flask-CORS’s CORS(app) does the same. FastAPI’s documentation examples for CORS middleware show allow_origins=["*"] in half the code samples before mentioning credentials at all.
A developer following the path of least resistance — which is what frameworks are supposed to provide — can configure CORS in eight lines of code and deploy to production without ever seeing a warning about the credentials interaction. The browser won’t warn them either; it just blocks the request silently, and when the developer tests with curl or Postman (which don’t enforce CORS), everything works.
“I’d bet my signing bonus that 60 percent of the developers running allow_origins=["*"] in production have no idea whether their API uses cookies or not,” one security engineer at a major cloud provider told me over Slack DM this week. “The framework said ‘add this to make it work,’ so they did.”
Web Security Became a Specialization, and We Pretended It Didn’t
The browser security model circa 2015 was manageable for a competent full-stack developer: understand the same-origin policy, set cookies with HttpOnly and Secure, add a CSRF token, move on. The model in 2026 involves CORS preflights, credentialed fetches, SameSite cookie attributes with three distinct modes, Sec-Fetch headers, CORP, COEP, COOP, and a CSP directive list long enough to require its own linter.
None of these mechanisms are individually irrational. Each solves a real attack vector. But the cumulative effect is a security boundary that requires borderline-expert knowledge to configure correctly — deployed in an industry where the median web developer has been writing JavaScript for three years and learned backend development from YouTube tutorials that skip CORS entirely because the demo uses localhost:3000 hitting localhost:8000 and the browser doesn’t care.
The Bureau of Labor Statistics says there are roughly 1.5 million software developers in the United States. The number of people who can explain, without reaching for a diagram, what happens when a fetch() call with credentials: 'include' hits a server that returns Access-Control-Allow-Origin: * is perhaps twenty thousand. The math doesn’t work. You cannot secure a platform by requiring every practitioner to have the threat-modeling skills of a staff security engineer.
The Fix Nobody Wants to Discuss
CISA’s Known Exploited Vulnerabilities catalog added CVE-2026-32610 four days ago — part of a grim 2026 trend where vulnerability exploits, not phishing, have become the primary intrusion vector according to Cisco Talos’s latest incident response report. The irony is thick: the mechanism designed to prevent cross-origin data theft is now a reliable vector for it, because the configuration surface area has outgrown the average developer’s ability to audit it.
There are exactly two serious paths forward, and neither involves writing another “developers don’t understand CORS” blog post.
Option one is tool-enforced safety. Browsers could refuse to send credentialed requests to wildcard origins entirely, rather than blocking silently in a way that breaks only in production. Framework CORS middleware could ship with allow_credentials=False and require an explicit, hard-to-accidentally-pass parameter to enable it — the way dangerouslySetInnerHTML in React forces developers to acknowledge they’re doing something risky. Linting rules in CI/CD pipelines could flag * origins combined with any credential-adjacent configuration.
Option two is simpler, and harder: admit that CORS, as architected, is a fragile ad-hoc layer bolted onto the same-origin policy, and begin the work of replacing it with something that doesn’t require every API developer to become a browser security specialist. No proposal with that ambition has gained traction in the W3C or WHATWG, because browser vendors and large platform companies — whose own security teams are fully staffed — benefit from a status quo where the complexity acts as a barrier to entry for smaller competitors.
In the meantime, CVE-2026-32610 will not be the last CORS vulnerability. It won’t even be the last one this quarter. And the developer who shipped it isn’t lazy, ignorant, or careless. They followed the framework’s defaults, tested locally, and shipped. The system was supposed to catch them. It didn’t.