Weekly security intelligence digest covering the most critical vulnerabilities, threats, and breach news from the past week.

🚨 Critical: CISA Known Exploited Vulnerabilities

These vulnerabilities are being actively exploited in the wild. Immediate action required.

CVE-2026-3910: Google Chromium V8 Improper Restriction of Operations Within the Bounds of a Memory Buffer Vulnerability

Vendor/Product: Google Chromium V8

Description: Google Chromium V8 contains an improper restriction of operations within the bounds of a memory buffer vulnerability that could allow a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera.

Required Action: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

CISA Due Date: 2026-03-27

Reference: CVE-2026-3910 - NVD

CVE-2026-3909: Google Skia Out-of-Bounds Write Vulnerability

Vendor/Product: Google Skia

Description: Google Skia contains an out-of-bounds write vulnerability that could allow a remote attacker to perform out of bounds memory access via a crafted HTML page. This vulnerability affects Google Chrome and ChromeOS, Android, Flutter, and possibly other products.

Required Action: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

CISA Due Date: 2026-03-27

Reference: CVE-2026-3909 - NVD

CVE-2025-68613: n8n Improper Control of Dynamically-Managed Code Resources Vulnerability

Vendor/Product: n8n n8n

Description: n8n contains an improper control of dynamically managed code resources vulnerability in its workflow expression evaluation system that allows for remote code execution.

Required Action: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

CISA Due Date: 2026-03-25

Reference: CVE-2025-68613 - NVD

đź“° This Week’s Security News

Poland’s nuclear research centre targeted by cyberattack

Poland’s National Centre for Nuclear Research (NCBJ) says hackers targeted its IT infrastructure, but the attack was detected and blocked before causing any impact. […]…

Read more: Poland’s nuclear research centre targeted by cyberattack

âś… What You Should Do This Week

  • Immediate: Patch CVE-2026-3910, CVE-2026-3909 (actively exploited)
  • Verify: Check your systems against CISA KEV catalog
  • Monitor: Review Azure AD sign-in logs for suspicious activity
  • Audit: Verify MFA is enforced for all privileged accounts
  • Backup: Test your disaster recovery procedures

đź’ˇ Expert Analysis

Let’s talk about what’s actually happening this week and why it matters.

Browser Zero-Days: The Attack Surface You Can’t Avoid

Two Google Chrome vulnerabilities hit CISA’s KEV list this week. Both actively exploited. Both allowing remote code execution through a crafted HTML page.

Translation: Someone sends you a link. You click it. Game over.

CVE-2026-3910 is a V8 engine bug - the JavaScript runtime that powers Chrome. CVE-2026-3909 affects Skia, the graphics library. Both are memory corruption vulnerabilities that let attackers break out of the browser sandbox and run code on your system.

Here’s what makes this scary:

These aren’t theoretical. CISA doesn’t add things to the KEV catalog based on “might be exploited someday.” They add them because exploitation is happening right now, in the wild.

Someone is actively using these bugs to compromise systems.

The Multi-Browser Problem

Chrome vulnerability means Edge is vulnerable. Means Brave is vulnerable. Means Opera is vulnerable. Means any Chromium-based browser is vulnerable.

Quick check: What browser do you use? What about your employees? Your executives?

If the answer includes Chrome, Edge, or anything Chromium-based (which is most browsers these days), you need to patch. Now.

But here’s the problem nobody talks about:

Even if you patch immediately, you’re relying on every single user to actually install the update. And we both know how that goes.

“I’ll restart my browser later.”
“I have 47 tabs open, I can’t close it now.”
“I’ll do it tonight.” (Spoiler: they won’t)

Meanwhile, the vulnerability sits there, waiting.

Why Browser Vulnerabilities Hit Different

Server vulnerabilities? You can patch those centrally. Network vulnerabilities? You control the infrastructure. Application vulnerabilities? You can push updates.

Browser vulnerabilities? You’re depending on users to click “Update now” instead of “Remind me later.”

And here’s the kicker:

Browsers are the most attacked software on the planet. Why? Because they’re the gateway to everything else.

Attackers don’t need to breach your firewall if they can just get your CFO to click a link. They don’t need to exploit your VPN if they can compromise a browser and steal session cookies.

Browser = the new perimeter.

The n8n Problem: When Workflow Tools Become Attack Tools

CVE-2025-68613 affects n8n, a workflow automation tool. Remote code execution through improper control of dynamically managed code.

Most people haven’t heard of n8n. But if your company uses workflow automation tools - Zapier, Make, n8n, etc. - pay attention.

Here’s the pattern:

These tools are designed to execute code dynamically. That’s literally their job. Take user input, run workflows, connect to APIs, execute scripts.

But “execute code dynamically” is also how you describe every remote code execution vulnerability ever.

The risk for financial services:

Workflow automation tools often have access to everything. Your CRM. Your email. Your database. Your payment processor. They’re the connective tissue between all your systems.

An attacker who compromises your workflow tool doesn’t just get one system. They get all of them.

Questions you should be asking:

  • Do we use workflow automation tools?
  • Who has access to create workflows?
  • What systems do those workflows connect to?
  • Are we monitoring for suspicious workflow executions?

If you can’t answer those questions, you have a problem.

The Nuclear Research Center Attack (That Didn’t Work)

Poland’s National Centre for Nuclear Research got attacked this week. The attack was detected and blocked.

That’s the good news.

The bad news? Someone tried to attack a nuclear research facility’s IT infrastructure.

Let’s be clear about what this means:

Attackers aren’t just going after financial data anymore. They’re going after critical infrastructure. Research facilities. Energy systems. The kind of targets where a successful breach could have physical consequences, not just data theft.

Financial services parallel:

You might think “we’re not a nuclear facility, this doesn’t apply to us.”

Wrong.

Financial services IS critical infrastructure. Your trading systems. Your payment networks. Your settlement systems. A successful attack doesn’t just steal data - it can freeze markets, prevent transactions, destabilize the financial system.

The fact that this attack was detected and blocked means their defenses worked. That’s the headline. But the fact that someone tried it at all should worry you.

What the Poland Attack Tells Us

We don’t have details on the attack. We don’t know who did it. We don’t know exactly what they tried.

But here’s what we can infer:

The attack was detected and blocked. That means:

  • They had monitoring in place
  • Their detection systems worked
  • Their incident response was fast enough

This is what good security looks like.

Not “we never get attacked.” That’s impossible. Good security is “we detect attacks and stop them before they cause damage.”

The questions you should ask yourself:

  • If someone tried to breach our network today, would we detect it?
  • How long would it take us to detect it?
  • Would we be able to block it before it caused damage?

If you hesitated on any of those, you’ve got work to do.

Browser Patching: The Uncomfortable Reality

Let’s talk about what you can actually do about browser vulnerabilities.

Option 1: Tell users to update their browsers

Pros: Easy
Cons: They won’t do it

Option 2: Force browser updates via policy

Pros: Actually works
Cons: Users will complain when their browser restarts mid-meeting

Option 3: Use browser isolation

Pros: Even if the browser gets compromised, the attacker is stuck in a container
Cons: Costs money, adds latency

Option 4: Hope for the best

Pros: Free, no effort required
Cons: You get breached

My recommendation: Combination of 2 and 3.

Force updates through group policy or MDM. Accept that sometimes browsers will restart at inconvenient times. Deal with the complaints. It’s better than dealing with a breach.

And for high-risk users (executives, finance, anyone with access to sensitive data), consider browser isolation. Yes, it costs money. Breaches cost more.

The Workflow Automation Risk Nobody Talks About

Back to n8n and workflow tools for a second.

The fundamental problem:

These tools are designed to be user-friendly. Point-and-click automation. No coding required. Anyone can create a workflow.

Which means:

Anyone can create a workflow that:

  • Pulls data from your database
  • Sends it to an external API
  • Runs arbitrary code
  • Accesses internal systems

And because it’s “just a workflow tool,” it doesn’t get the same security scrutiny as actual code.

No code review. No security testing. Just Bob from accounting creating a workflow to automate his monthly report.

Except now Bob’s workflow has access to the entire customer database. And if an attacker compromises Bob’s account (or the workflow tool itself), they get that access too.

What you should do:

Treat workflow automation tools like code. Because that’s what they are.

  • Require approval for workflows that access sensitive data
  • Monitor workflow executions for anomalies
  • Limit which systems workflows can connect to
  • Patch the damn tools when vulnerabilities come out

What Actually Matters This Week

Two browser zero-days. One workflow automation RCE. One successful defense against a critical infrastructure attack.

The pattern:

Attacks are getting more sophisticated (targeting nuclear research centers), but most breaches still happen through basic vectors (browser vulnerabilities, workflow tools).

The solution isn’t complicated:

Patch your browsers. Secure your automation tools. Monitor your networks. Have an incident response plan that actually works.

The Poland nuclear center didn’t avoid getting attacked. Nobody can. But their defenses worked. That’s the goal.

Not “never get attacked.” That’s impossible.

“Detect and stop attacks before they cause damage.” That’s achievable.

Need help building defenses that actually work? I spent five years securing a $124B pension fund. Let’s talk - first call is free.

📬 Stay Updated

Subscribe to receive weekly security digests directly in your inbox.

Questions or feedback? Contact us

GRC Vitrix provides cloud security and compliance intelligence for financial services professionals. This digest is curated from publicly available sources including CISA, Microsoft MSRC, and industry news.