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-35273: Oracle PeopleSoft Enterprise PeopleTools Missing Authentication for Critical Function Vulnerability

Vendor/Product: Oracle PeopleSoft Enterprise PeopleTools

Description: Oracle PeopleSoft Enterprise PeopleTools contains a missing authentication for critical function vulnerability which could allow an unauthenticated attacker to obtain takeover of PeopleSoft Enterprise PeopleTools.

Required Action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

CISA Due Date: 2026-06-15

Reference: CVE-2026-35273 - NVD

Expert take: This is the big one this week. CVSS 9.8, no login needed, full takeover. And it was already being used as a zero-day before Oracle even put out a patch.

Here’s the timeline that matters. Mandiant traced exploitation back to May 27, running until June 9. Oracle’s advisory didn’t come out until June 10. So attackers had roughly two weeks of a head start before anyone got a fix. ShinyHunters ran the campaign, they went after Environment Management Hub endpoints, and they were pulling data and posting it on their leak site.

One detail that should worry any GRC person: about 68% of the notified victims were universities and colleges. That’s not random. PeopleSoft runs HR and finance for a ton of schools and public sector orgs, so it’s a big pile of PII sitting behind one exposed service.

So what do you do. Patch is the real fix, but if you can’t move fast, block external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector at the firewall. And don’t just patch and walk away. Because this was exploited before the fix existed, you have to assume you might already be hit. Go look for signs of compromise, not just missing patches. That’s the part people skip.

CVE-2026-10520: Ivanti Sentry OS Command Injection Vulnerability

Vendor/Product: Ivanti Sentry

Description: Ivanti Sentry (formerly known as MobileIron Sentry) contains an OS command injection vulnerability which could allow a remote unauthenticated user to achieve root-level remote code execution. This vulnerability can be successfully exploited in cases where the Sentry appliance is in an unmanaged state with its endpoints externally reachable. The use of mTLS with EPMM or restricted HTTPS access through Neurons for MDM makes interfaces inaccessible to external actors.

Required Action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

CISA Due Date: 2026-06-14

Reference: CVE-2026-10520 - NVD

Expert take: Perfect 10.0. And the story here is speed. Ivanti patched on June 9 and said they had no sign of attacks. A researcher dropped a working exploit the next day. By that same day, attackers were already backdooring boxes.

The root cause is almost funny in how basic it is. There’s an internal config API (/mics/api/v2/sentry/mics-config/handleMessage) that was just left open with no auth. Send it a crafted message and it runs your commands as root. Something built to be “internal only” ended up reachable from the internet, and nobody put a lock on it.

Why care about Sentry specifically. It’s a gateway that sits between mobile devices and your internal systems. So it’s meant to be a wall. Compromise it and you’re not outside the network anymore, you’re standing on the wall holding credentials and session tokens. That’s a nasty foothold.

Shadowserver saw 19 exposed instances and at least 2 already backdoored, and their honest read was “if you haven’t patched, assume you’re compromised.” So same drill as PeopleSoft: patch to R10.5.2 / R10.6.2 / R10.7.1, make sure the management port (8443) is not facing the internet, and go hunt. Check for new admin accounts too, since the companion bug (CVE-2026-10523) lets attackers create their own.

CVE-2026-11645: Google Chromium V8 Out-of-Bounds Read and Write Vulnerability

Vendor/Product: Google Chromium V8

Description: Google Chromium V8 out-of-bounds read and write 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-06-23

Reference: CVE-2026-11645 - NVD

Expert take: V8 is Chrome’s JavaScript engine, and out-of-bounds read/write bugs there are the classic “just visit a bad web page” problem. No click needed beyond loading the page.

Worth being clear about the scope. This isn’t only Chrome. Anything built on Chromium is in scope, so Edge, Opera, Brave, and a pile of Electron apps too. That means the number of things you need to update is bigger than most people picture. And it’s the same engine everywhere, so one bug patches across a lot of surfaces at once, which is the good news.

The fix is boring and works: let the browser update and restart it. The catch is the restart. People leave Chrome open for weeks, the update downloads but never actually applies. If you manage endpoints, push the browser update and force the relaunch, don’t trust everyone to close their tabs.

CVE-2026-7473: Arista Extensible Operating System Incomplete Comparison with Missing Factors Vulnerability

Vendor/Product: Arista Extensible Operating System

Description: Arista Extensible Operating System (EOS) contains an incomplete comparison with missing factors vulnerability when the switch incorrectly decapsulate and forwards other unexpected tunneled packet with a destination IP matching its configured decapsulation IP.

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-06-23

Reference: CVE-2026-7473 - NVD

Expert take: This one’s more niche, but it matters if you run Arista gear in your core. The switch is supposed to only decapsulate tunnel traffic aimed at its own decapsulation IP. It’s checking that wrong, so it’ll unwrap and forward packets it shouldn’t.

Why that’s bad: it’s a way to sneak traffic past network boundaries. If a switch decapsulates something it wasn’t meant to, an attacker can potentially route packets into segments that were supposed to be walled off. So your network segmentation, the thing you’re leaning on to contain a breach, quietly stops working the way you drew it on the diagram.

This is a config-and-patch situation, not something end users touch. Get your network team to apply the EOS fix and double check which decapsulation IPs are configured. The broader point for GRC folks: segmentation is a control you’re probably claiming in your SOC 2 or your risk assessment. A bug like this is a reminder that the control is only as good as the box enforcing it.

CVE-2026-20245: Cisco Catalyst SD-WAN Manager Improper Encoding or Escaping of Output Vulnerability

Vendor/Product: Cisco Catalyst SD-WAN Manager

Description: Cisco Catalyst SD-WAN Manager formerly SD-WAN vManage contains an improper encoding or escaping of output vulnerability. This vulnerability could allow an authenticated, local attacker to execute arbitrary commands as root by supplying a crafted file to the affected system.

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-06-23

Reference: CVE-2026-20245 - NVD

Expert take: Read the fine print on this one. It needs an authenticated, local attacker. So it’s not the “anyone on the internet” panic that the PeopleSoft and Ivanti bugs are. That lowers the urgency a notch.

But don’t dismiss it. It’s a privilege escalation to root. So the real risk is chaining: someone gets a low-level foothold or a stolen set of credentials, then uses this to jump to full root on your SD-WAN controller. And SD-WAN Manager is the brain that controls your whole wide-area network. Root there is about as bad as it gets for a network team.

The reason it’s still on the KEV list is that “needs authentication” doesn’t mean “safe.” Credentials leak, insiders exist, and other bugs get chained. Patch it in your normal urgent cycle. It’s not a drop-everything like the top two, but it shouldn’t sit in the backlog either.

đź“° This Week’s Security News

Maine disables data breach notification portal after fake disclosures

Maine has taken its public data breach reporting portal offline after fraudulent breach disclosures were published on the state’s website, prompting a review of procedures to prevent abuse in the futu…

Read more: Maine disables data breach notification portal after fake disclosures

Expert take: This is a different kind of problem and it’s a good one to think about. Nobody hacked anything. People just submitted fake breach notices to a portal that published them without checking.

That’s an abuse-of-process issue, not a technical exploit. The system worked exactly as designed, which was the flaw. Any public-facing form that takes submissions and posts them without a review step will eventually get filled with garbage or worse. Fake disclosures can spook customers, move markets, or just waste everyone’s time.

The fix isn’t a patch, it’s a workflow. Add verification before anything goes public. If you run any intake form, a compliance portal, a status page, a public disclosure page, ask yourself what happens when someone lies to it on purpose. That’s a threat model people forget because they only picture attackers breaking in, not attackers using the front door as intended.

Ukrainian national pleads guilty to role in Conti ransomware operation

A Ukrainian national extradited from Ireland to the United States last year has pleaded guilty to conspiracy charges tied to the Conti ransomware operation. […]…

Read more: Ukrainian national pleads guilty to role in Conti ransomware operation

Expert take: Good news, and rare. These cases take years, and Conti was one of the nastier operations out there before it fell apart. A guilty plea means the extradition and the evidence held up.

Don’t read too much into it though. Conti didn’t really die, it splintered. The people scattered into other groups and kept going. So one guilty plea is a win, but it doesn’t shrink the actual threat much. Ransomware is a business, and taking out one operator doesn’t close the business.

The practical takeaway is boring but real: your defense can’t depend on law enforcement catching people. Arrests happen way after the damage. You still need offline backups you’ve actually tested, MFA everywhere, and a plan you’ve rehearsed. Enforcement is a nice tailwind, not a control you get to rely on.

Early Warning Signs of Supply-Chain Attacks Live in the Dark Web

GitHub access sales, leaked repositories, and stolen API keys can all become supply-chain attack footholds. Flare explores how underground forums expose early signals tied to software supply-chain ris…

Read more: Early Warning Signs of Supply-Chain Attacks Live in the Dark Web

Expert take: The idea here is simple and it’s right. A lot of supply-chain attacks start with something small getting sold or leaked first. A GitHub login, a repo dump, an API key someone committed by accident. The break-in comes later.

So there’s often a window. The stolen thing shows up on a forum before it gets used. If you’re watching for your own stuff out there, you sometimes get a heads-up before it turns into an incident.

Two practical things. First, the cheapest win is not leaking keys in the first place, so scan your repos for secrets and rotate anything that’s been sitting in git history. Second, if you can, keep an eye on the places your credentials would show up for sale. You don’t need a fancy threat intel program. Even basic secret scanning plus watching for your domains and repo names catches a lot. The whole point is to move the detection earlier, before someone logs in with your own key.

âś… What You Should Do This Week

  • Immediate: Patch CVE-2026-35273, CVE-2026-10520 (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

📬 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.