Knowledge
Chrome Had a Bad Week. Your Website Has a Job to Do.
An actively exploited Chrome zero-day was patched this week. It was the fifth this year. Here's what it has to do with a common finding in our website scans: the missing Content-Security-Policy header.
June 12, 2026 · Confidanti · 3 min read
- news
- chrome
- csp
- layers
- vulnerabilities
On June 9, Google shipped an emergency update for Chrome. The reason: CVE-2026-11645, a flaw in the engine that runs JavaScript inside the browser, serious enough that a maliciously crafted web page can use it to run code on the visitor's machine. This wasn't a precaution — the bug was being actively exploited before the patch existed, and the US cybersecurity agency CISA added it to its catalog of must-patch vulnerabilities the same day.
It's Chrome's fifth actively exploited zero-day this year. That's not a knock on Google, finding and fixing these fast is the system working. But it confirms something worth internalizing: the browser is a security layer that fails several times a year, on a schedule nobody controls.
First things first: update Chrome today. The browser downloads updates by itself, but they only take effect on relaunch — and many of us haven't relaunched in weeks. Check the top-right corner for the update pill, or visit Settings → About Chrome, and fully restart it. The same engine sits inside Edge, Brave, and Opera, so update those too if your team uses them.
What this has to do with your website
Fair question. A browser bug is Google's problem, not yours. Here's the connection, and it comes straight from our own scan reports.
One of the most common findings when we scan a business's website is this one:
LOW — Missing Content-Security-Policy header No CSP header set; XSS mitigation depends solely on browser defaults.
Read that last part again: depends solely on browser defaults. It means the website has opted to have exactly one line of defense against malicious scripts: the visitor's browser. The same browser that just needed its fifth emergency patch of the year.
A Content-Security-Policy header is the website's own allowlist: it tells every visiting browser which scripts are allowed to run on your pages, and everything else is refused. Without it, an attacker who finds any way to slip a script into your site — through a vulnerable form, an outdated plugin, a compromised third-party widget — gets free rein in your customers' browsers. Injected scripts can steal login sessions, skim the payment form, or quietly redirect your visitors to a page serving exploits for bugs exactly like this week's. In that scenario, the missing header on your site becomes the compromise of your customers' machines with your name on the page where it happened.
CSP exists to break that chain. When the first defense misses — and weeks like this one prove that sometimes it does — the header is what stands between an injected script and your visitors.
Why we score it LOW, and report it anyway
Severity ratings describe the risk of a finding on its own, today: a missing CSP header doesn't open a door by itself, so it scores LOW. What the rating can't capture is the blast radius when another layer fails: the plugin that turns out to be vulnerable, the browser that turns out to be exploitable. That's precisely why it appears on every report: LOW means "not urgent in isolation" NOT "safe to ignore forever." Defense in depth is built on closing exactly these gaps during the calm weeks, so the loud weeks stay uneventful.
The fix is a configuration change, not a project: your developer or hosting provider can add the header, starting in report-only mode to see what it would block, then enforcing it. An afternoon of work for a layer you control completely. Then you don't need to wait on anyone's emergency patch.
Want to know what your website's headers tell an attacker? An exposure scan is the first step of every Confidanti engagement — talk to us.