Critical SharePoint RCE CVE-2026-50522 Under Active Exploitation After Public PoC

A third SharePoint Server flaw patched by Microsoft as part of its Patch Tuesday update for July 2026 has come under active exploitation, per watchTowr.

The vulnerability in question is CVE-2026-50522 (CVSS score: 9.8), a critical deserialization of untrusted data in Microsoft Office SharePoint that could allow an unauthorized attacker to execute code over a network. Microsoft credited DEVCORE researcher "splitline" with discovering and reporting the flaw.

"In a network-based attack, an attacker authenticated as at least a Site Owner, could write arbitrary code to inject and execute code remotely on the SharePoint Server," Redmond said in an advisory released last week.

"The attack vector is Network (AV:N) because this vulnerability is remotely exploitable and can be exploited from the internet. The attack complexity is Low (AC:L) because an attacker does not require significant prior knowledge of the system and can achieve repeatable success with the payload against the vulnerable component."

The tech giant also tagged CVE-2026-50522 with an exploitability assessment of "Exploitation More Likely."

In a post shared on LinkedIn, watchTowr said it has detected active exploitation of the shortcoming against on-premises Microsoft SharePoint deployments following the release of a public proof-of-concept (PoC) exploit, allowing attackers to steal machine keys to maintain persistent access.

"Attackers are pulling SharePoint machine keys via a single request," the security vendor said. "Patching is not enough; defenders should rotate credentials on any assets that may have been exposed."

CVE-2026-50522 is the third vulnerability in SharePoint Server after CVE-2026-56164 (CVSS score: 5.3) and CVE-2026-58644 (CVSS score: 9.8) to witness active exploitation efforts, with the latter two weaponized as zero-days prior to them being fixed in July 2026.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has since warned that threat actors are exploiting multiple SharePoint Server vulnerabilities, including CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, and CVE-2026-58644, to gain unauthorized access to on-premises instances.

"These vulnerabilities affect all supported on-premises SharePoint Server versions (Subscription Edition, 2019, and 2016) and involve establishing remote code execution (RCE) and post-exploitation activities, such as stealing Internet Information Services (IIS) machine keys and performing deserialization techniques, to gain persistence and deploy malware," the agency said.

from The Hacker News https://ift.tt/3Qmzjx4
via IFTTT

Zimbra Patches Critical SNMP Command Injection and Four XSS Vulnerabilities

Zimbra has rolled out fixes to address multiple critical security issues, including a command injection flaw in the Simple Network Management Protocol (SNMP) monitoring component.

As many as nine security vulnerabilities have been patched in Zimbra 10.1.20. Topping the list is a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled.

Also patched are four cross-site scripting (XSS) flaws in the Classic Web Client -

• A stored cross-site scripting (XSS) vulnerability that could allow malicious attachment filenames to execute script under specific conditions.
• An XSS vulnerability where crafted fields could execute a malicious script under specific conditions.
• An XSS vulnerability where a crafted field could execute a malicious script when rendered.
• An XSS vulnerability where crafted attachments could execute a malicious script when rendered.

Separately, fixes have been released for a mail forwarding restriction bypass (CVE-2026-50055) that could allow authenticated users to exfiltrate email despite mail forwarding restrictions being enabled. Rapid7 security researcher Jonah Burgess has been credited with discovering and reporting the flaw.

The company did not share any additional specifics, stating "in line with industry best practices, information disclosure is limited for security vulnerability fixes."

The release comes a little over a week after Zimbra patched a critical stored XSS flaw in the Classic Web Client that could result in arbitrary code execution.

Although none of the identified vulnerabilities have been flagged as actively exploited, XSS bugs in the email software have been repeatedly exploited by bad actors in the past, making it crucial that customers apply the updates to keep the environment secure.

from The Hacker News https://ift.tt/Fk7xjhX
via IFTTT

How to Upgrade Debian 12 to Debian 13 (Trixie) with Minimal Downtime

Debian 13 (Trixie) is now stable, and Debian 12 is in LTS-only support. Our new guide covers a production-focused upgrade path to Debian 13, including backups, rolling deployments, and common pitfalls to minimize service disruption.

Debian 13 “Trixie” has been the stable release since August 9, 2025, and Debian 12 “Bookworm” is now oldstable. Its full security support window closed around June 2026, leaving it on LTS-only coverage. If you’re still running Bookworm in production, upgrading is no longer optional; it’s a matter of when. This guide walks through a full 12-to-13 upgrade with a specific focus on minimizing downtime on live, service-critical servers, not just a lab box you can afford to take offline for an afternoon.

What’s New in Debian 13 Trixie (Quick Context)

Debian 13 ships Linux kernel 6.12 LTS, GCC 14.2, Python 3.13, and over 14,100 updated packages, with full support running until roughly August 2028 and LTS extending to 2030. For production servers, the practical takeaway isn’t the flashy features; it’s that the security support clock has reset, and every month spent on Bookworm’s shrinking support window is technical debt you’ll eventually have to pay down anyway.

Important Constraint: You Can Only Upgrade From Debian 12

Debian only supports upgrading between consecutive stable releases. If you’re on Debian 11 “Bullseye” or older, you must upgrade to Debian 12 first, then to Debian 13; there’s no direct 11-to-13 path.

The “No Downtime” Strategy: What This Actually Means

Be realistic about what “without downtime” means for a major OS upgrade: the goal isn’t zero risk; it’s minimizing user-facing service interruption through preparation, sequencing, and a tested rollback path. The core techniques that make this achievable:

1. Test in staging first, never run your first Trixie upgrade on a production box
2. Take a snapshot or full backup immediately before the upgrade, so rollback is a restore, not a rebuild
3. Use apt upgrade –without-new-pkgs before full-upgrade to reduce the risk of mid-upgrade service breakage
4. Drain traffic from the server first if it’s part of a load-balanced fleet, rather than upgrading it live
5. Upgrade one node at a time across a fleet, verifying each before moving to the next

How to Upgrade Debian 12 to Debian 13 (Trixie) Without Downtime

To upgrade Debian 12 to Debian 13 (Trixie) without downtime, first fully patch and reboot your Debian 12 system, back up /etc and your package selections, and disable any third-party repositories that may not yet support Trixie. Then point your APT sources from bookworm to trixie using sudo sed -i ‘s/bookworm/trixie/g’ /etc/apt/sources.list, run sudo apt update, and perform the upgrade in two stages: sudo apt upgrade –without-new-pkgs -y first to safely resolve dependencies, followed by sudo apt full-upgrade -y to complete the transition.

If the server is part of a load-balanced fleet, drain its traffic before starting and re-add it only after verifying all services are healthy post-reboot. This rolling, one-node-at-a-time approach is what actually eliminates user-facing downtime across a production environment.

Step 1: Back Up Everything Before You Touch Anything

This is non-negotiable. A dist-upgrade preserves data and configuration in the vast majority of cases, but “in the vast majority of cases” is not a guarantee; your backup is your actual rollback plan if something breaks mid-upgrade.

sudo tar -czf /backup/etc-backup-$(date +%Y%m%d).tar.gz /etc

sudo dpkg --get-selections > /backup/package-selections-$(date +%Y%m%d).txt

If you’re on a VM, take a full snapshot through your hosting provider or hypervisor; this is faster to restore from than a manual file backup and covers everything, not just /etc.

Step 2: Fully Patch Debian 12 Before Upgrading

Never jump to Trixie from a partially updated Bookworm system. Bring the current OS fully current first:

sudo apt update

sudo apt full-upgrade -y

 

 

Reboot to ensure the current kernel is fully applied and no pending changes are left hanging before you introduce the bigger upgrade.

sudo apt autoremove -y

sudo reboot

 

 

Step 3: Check for Held or Locked Packages

Held packages can silently break a major upgrade. Check for any before proceeding:

apt-mark showhold

 

 

If anything critical to the upgrade is listed, remove the hold:

sudo apt-mark unhold <package-name>

Step 4: Verify Free Disk Space

A major version upgrade downloads and temporarily stores a large number of packages. Confirm you have enough headroom, particularly on / and /boot:

df -h

 

 

You’ll typically want at least 2–3 GB free on /, and Trixie’s release notes specifically call out ensuring /boot has enough free space, since kernel packages have grown in size.

Step 5: Disable Third-Party Repositories Temporarily

Third-party repos (Docker, Node.js, PostgreSQL, etc.) are one of the most common causes of upgrade failures, since they may not yet have Trixie-compatible packages. Check what’s configured:

cat /etc/apt/sources.list

ls /etc/apt/sources.list.d/

 

 

Temporarily disable them by renaming rather than deleting, so you can restore them cleanly afterward:

sudo mv /etc/apt/sources.list.d/docker.list /etc/apt/sources.list.d/docker.list.bak

Step 6: Point Your Repositories to Trixie

The core of the upgrade is simple: swap every bookworm reference to trixie in your APT sources.

sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

 

 

If your system uses the newer DEB822 .sources format (common on more recent Debian 12 installs), update those too:

sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.sources 2>/dev/null

 

 

Trixie also officially encourages consolidating to the DEB822 format going forward, but it’s not required for the upgrade to succeed.

Step 7: Refresh Package Metadata

A handful of warnings about changed repository signatures during this step are normal for a major version transition and not a sign of a problem.

sudo apt update

 

 

Step 8: Run the Minimal Upgrade First (This Is the Downtime-Reducing Step)

This is the most important step for minimizing service disruption. Instead of jumping straight to a full upgrade, run a minimal upgrade first, one that resolves dependencies without removing or installing new packages:

sudo apt upgrade --without-new-pkgs -y

 

 

You’ll likely see “packages have been kept back” messages; this is expected and normal. This step resolves the safer, lower-risk package updates first, reducing the chance of a service getting yanked mid-transaction during the bigger step that follows.

Step 9: Run the Full Upgrade

Once the minimal upgrade completes cleanly, proceed with the full distribution upgrade:

sudo apt full-upgrade -y

 

 

This resolves the held-back packages by installing new dependencies or removing conflicting ones. This step takes the longest; don’t interrupt it, especially during kernel or GRUB package installation. If prompted about where to install GRUB, choose the disk your system currently boots from (typically /dev/sda or /dev/vda).

Step 10: Clean Up and Reboot

sudo apt clean

sudo apt autoremove -y

sudo reboot

 

 

After rebooting, let’s confirm the upgraded Debian 13.

 

 

Step 11: Verify the Upgrade

After reboot, confirm you’re actually running Trixie:

cat /etc/os-release

 

 

Or, on systemd-based installs:

hostnamectl

 

 

You should see Debian GNU/Linux 13 (Trixie) and 6.12.x kernel versions.

Minimizing Downtime Across a Fleet of Servers

If you’re managing multiple servers behind a load balancer, the real downtime-avoidance strategy happens at the infrastructure level, not just the OS level:

1. Remove the server from the load balancer pool before starting the upgrade, so it stops receiving live traffic
2. Upgrade and fully verify the drained node using the steps above
3. Re-add it to the pool only after confirming all critical services are healthy
4. Repeat one node at a time, never upgrading multiple nodes simultaneously

This turns what would otherwise be a single point of downtime into a rolling upgrade with zero visible interruption to end users.

Known Gotchas in Trixie’s Release Notes Worth Knowing

A few changes specifically called out in Debian’s official release notes have tripped up production upgrades:

• /tmp is now mounted as tmpfs by default; applications writing large temporary files may behave differently
• OpenSSH no longer supports DSA keys; audit your key types before upgrading if you rely on SSH automation
• /etc/sysctl.conf is no longer honored directly; move custom kernel parameters to /etc/sysctl.d/
• MariaDB major version upgrades only work reliably after a clean shutdown. Stop the service properly before upgrading if you’re running MariaDB
• Troubleshooting Common Issues

“Unable to locate package” errors during apt update usually mean a third-party repo is still pointing to bookworm. Disable it and retry.

Services fail to start after reboot. Check logs directly:

sudo journalctl -xe

sudo systemctl status <service-name>

 

 

Configuration file format changes between major versions are the most common cause.

Need to roll back. If your backup was a VM snapshot, restore it directly. If not, you can attempt to revert sources to bookworm, but a clean rollback via snapshot is far more reliable than trying to downgrade packages manually.

Final Thoughts

Upgrading Debian 12 to Debian 13 without downtime isn’t about finding some special zero-risk trick; it’s about disciplined preparation: full backups before you start, a fully patched source system, third-party repos handled deliberately, the minimal-upgrade-then-full-upgrade sequence, and load balancer draining if you’re managing more than one server.

Follow that order, and the upgrade itself typically takes under an hour per server, with the biggest real risk coming from custom configurations and unmaintained third-party repositories rather than Debian’s own upgrade tooling.

FAQ

Can I upgrade directly from Debian 11 to Debian 13?

No. Debian only supports upgrades between consecutive stable releases, so you must upgrade from Debian 11 “Bullseye” to Debian 12 “Bookworm” first, and only then proceed to Debian 13 “Trixie.”

Will upgrading from Debian 12 to Debian 13 delete my data or configuration?

A standard dist-upgrade preserves data and configuration in the vast majority of cases, since it upgrades packages rather than reinstalling the system. That said, a full backup or VM snapshot is still mandatory beforehand; it’s your rollback plan if anything goes wrong mid-upgrade, not an optional precaution.

Why should I run apt upgrade –without-new-pkgs before apt full-upgrade?

This two-stage approach resolves the safer, lower-risk package updates first without installing or removing anything, reducing the chance of a critical service being disrupted mid-transaction during the larger, more disruptive full upgrade that follows. It’s the key technique for minimizing downtime risk on production servers.

How long does the Debian 12 to Debian 13 upgrade actually take?

For a well-maintained server, the entire process, backup, repository switch, minimal upgrade, full upgrade, and reboot, typically takes under an hour. The biggest variable is the package download speed and how many third-party repositories need to be checked for Trixie compatibility.

What’s the safest way to upgrade multiple production servers without any visible downtime?

Upgrade one server at a time rather than all at once: remove it from your load balancer pool first, complete and verify the upgrade in isolation, then add it back only after confirming services are healthy.

from StarWind Blog https://ift.tt/Puq9xEj
via IFTTT

New Bit2Watt Attack Could Let Cloud Tenants Disrupt Power Grids Without an Exploit

A cloud tenant using nothing but ordinary GPU access can push a data center's power draw up and down fast enough to threaten the grid it runs on, with no exploit and no break-in.

That is the claim behind Bit2Watt, described by three Zhejiang University researchers in a paper accepted to CHES 2026, the IACR's hardware-security conference, and the evidence splits in two: they measured the power modulation on real GPUs and simulated the grid destabilization it could cause.

The technique inverts the usual grid-attack model: no compromised sensors, no malware on control systems, no stolen operator credentials, just a workload built to misbehave on purpose.

It works because a GPU's power draw follows whatever it is computing. Saturate the tensor cores and current spikes; drop to idle, and it collapses. Toggle between those states on a schedule and you get a controllable power oscillation at the wall socket.

The authors frame it as a blunt question: can "purely computational actions, executed as legitimate workloads, be weaponized to destabilize power infrastructure"? The rest of the paper is their answer.

Two Ways In

The first method, which they call SWMA, uploads a purpose-built CUDA kernel that flips between a high-intensity compute mode and a near-idle one. A host-side controller sets the switching schedule and toggles the mode through a single unified-memory flag allocated with cudaMallocManaged, standard tooling rather than anything exotic.

Across the tested GPUs, the synthetic workload produced power components from about 1.5 kHz up to 6 kHz, peaking on an RTX 4090, well above the handful of hertz a swinging household load like an air conditioner produces.

It held on data-center GPUs like the A100 and Tesla V100, not just gaming cards. The custom kernel and its tight polling loop are the sort of thing a provider could learn to fingerprint.

The second, LTMA, is the one that should worry operators. Rather than a synthetic kernel, it buries the modulation inside a real LLM training run, adjusting hyperparameters and inserting auxiliary operations to make the compute load rise and fall without breaking the training.

The control is looser than SWMA's, bounded by how fast the training loop iterates, and the frequencies run lower, roughly 1.2 to 3 kHz. But it reaches larger amplitude and blends into normal training noise, which is exactly what makes it the harder one to flag. Neither method needs elevated privileges, because a tenant already controls their own training scripts and job schedules.

Those are single-GPU figures, and they only bite in bulk. The paper models the bulk case at its most dangerous: a simulated 1 MW local grid, 90% powered by distributed energy resources (the rooftop solar and batteries increasingly feeding local grids), with 1,000 GPUs modulating in perfect lockstep.

In that worst-case simulation, current total harmonic distortion (THD) hit 46.8%, well above the 13% guideline the paper benchmarks it against from IEC 61000-3-12. The damping ratio fell to -0.27, a negative value that marks an unstable mode, where the grid amplifies a disturbance instead of damping it out.

The paper pushes the model further still, onto a 9,241-bus grid meant to resemble the European transmission network, where a localized disturbance worth 2% of system load cascades across 13 stages and sheds about 81% of load. That number stacks worst-case assumptions on one specific model, and it is a property of the simulation, not a forecast of anything real.

That lockstep is the load-bearing assumption, and the optimistic one for the attacker: the paper concedes that aligning power transitions across a real fleet of cloud GPUs is still an open problem. In its own 2 kHz model, timing jitter with a standard deviation of 100 microseconds cut the aggregate amplitude by about 20%, and the paper does not claim that figure reflects a typical cloud.

A real attack would need several things to line up at once: enough physically clustered GPUs, tight synchronization across them, modulation that survives the data center's power-conditioning stages, and a grid whose resonances happen to amplify the chosen frequency.

The physical experiments ran in controlled testbeds, and the grid-scale damage came from simulation, with no production systems attacked and no security flaw disclosed in any specific commercial product.

The Hacker News has reached out to the Zhejiang University researchers for comment on how far the attack scales in a real cloud environment and will update this story with any response.

What keeps it from being purely academic is that the physics is already on record. In August 2025, Microsoft, OpenAI, and NVIDIA published their own paper on stabilizing AI-training power, warning that the synchronized swings of large training jobs can, when their frequency lines up with a utility's critical frequencies, "cause physical damage to the power grid infrastructure."

Bit2Watt takes that accidental effect and asks what a tenant could do with it deliberately.

The grid has also had a scare from data centers behaving badly by accident. In July 2024, a transmission fault in a data-center-dense part of Northern Virginia caused roughly 1,500 MW of data-center load to drop off the grid at once, when the facilities' own protection systems cut them over to backup power.

NERC, which oversees North American grid reliability, said the disturbance posed no reliability risk at the time, though operators did have to correct voltage. It warned that the danger grows as these loads scale, and its technical committee set up a Large Loads Task Force later in 2024 to study them.

No one attacked anything; the data centers protected themselves. The point is not that the grid nearly failed, but that a load that size can drop in an instant, faster than operators can plan for, and the risk climbs as these fleets grow.

The loop closes with what the authors call Watt2Bit, the disturbance feeding back into the computing side. The paper's analysis shows how harmonic-driven heating and elevated current could trip thermal or overcurrent protection and shut GPU servers down, turning a power-quality problem into a denial of service.

Stranger still, the same modulation doubles as a covert channel. Encoding bits as two frequencies, 2 kHz for a 1 and 200 Hz for a 0, the team captured the electromagnetic emissions on a near-field antenna wired to a software-defined radio and recovered a 50-bit test sequence with zero errors.

It is a close cousin of PowerHammer, the air-gap data-exfiltration attack THN covered in 2018, with one distinction: PowerHammer read data conducted along the power line, tapped anywhere from the outlet to the building's electrical panel, while Bit2Watt's channel needs an antenna catching near-field EMI right at the hardware.

Neither reaches out over the internet; both need a physical foothold near the power or the machine.

No Bug to Patch

Standard telemetry barely catches it. Rack PDU counters sample once a second, NVIDIA's NVML telemetry at 450 Hz, and even the fastest common interfaces, RAPL and server BMCs, top out near 1 kHz, while the modulation runs several times higher.

A lightweight detector the researchers built on power and NVML data performed poorly; adding GPU profiling features improved it, and dedicated EMI sensing worked best. LTMA was consistently harder to spot than SWMA. Those results come from a research-grade detector, not the proprietary systems a large cloud provider might run, so they do not prove a hyperscaler would miss it.

The bigger problem is not visibility. There is no product bug to patch, because the exposure is the architecture itself: the tight coupling between volatile GPU load and an inverter-heavy grid, which no conventional monitoring watches across.

The paper offers defenses for both sides at once: batteries, supercapacitors, and harmonic filtering on the power side; anomaly detection on GPU utilization and training schedules on the compute side. It frames a single system that ties the two together as future work.

The compute side and the grid side are run by different companies, monitored by different tools, and neither is built to watch the other. That seam is where Bit2Watt lives, and right now it has no owner.

from The Hacker News https://ift.tt/D5wNrkZ
via IFTTT

WordPress wp2shell Exploitation Grows as Public Exploit Fuels Mass Scanning

Attackers have begun to exploit two critical vulnerabilities in WordPress that, when combined together, enable unauthenticated remote code execution (RCE) and complete compromise of vulnerable websites.

The two security flaws, tracked as CVE-2026-63030 and CVE-2026-60137, have been codenamed wp2shell.

"By the early hours of Saturday morning (UTC), successful exploitation was already well underway, initially using public exploit code to exfiltrate hashed credentials, with remote code execution following once additional details were made public," Jake Knott, principal security researcher at watchTowr, told The Hacker News in a statement.

"From our vantage point across a global client base, we are seeing widespread impact of this vulnerability across organizations of every size and every vertical."

Telemetry data captured by KEVIntel shows that 13 unique IP addresses from Switzerland, Germany, the U.K., Indonesia, Lithuania, the Netherlands, and Singapore have been linked to the exploitation of CVE-2026-63030.

The exploit chain, discovered by Searchlight Cyber using OpenAI GPT 5.6 Sol in over 10 hours, essentially allows unauthenticated attackers to gain remote code execution on default WordPress installations in any WordPress version released since December 2025. Technical details have been withheld in light of the severity of the issue.

"The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins," Searchlight Cyber said.

According to Cloudflare, CVE-2026-63030 enables unauthenticated remote code execution (RCE) only when persistent object cache is not in use. While the SQL injection vulnerability (CVE-2026-60137) is present from version 6.8 onwards, the RCE affects versions from 6.9.

"This exploit utilizes a two-part vulnerability chain to achieve unauthenticated SQL injection on a stock WordPress installation with a single HTTP request," Ben Marr, security engineer at Intruder, explained. "CVE-2026-60137 is the entry point - a route confusion bug in the REST API batch endpoint that bypasses authentication, allowing an attacker to invoke internal handlers without any permission check."

"This flaw arises from the improper sanitization of the 'author__not_in' parameter within 'WP_Query' when untrusted data is passed to it by a plugin or theme. This vulnerability allows crafted input to alter a database query, potentially leading to unauthorized access or manipulation of data."

Data from Google-owned Wiz suggests that 60% of organizations using WordPress initially had at least one vulnerable instance at the time these CVEs were published, and 25% were exposing a vulnerable server to the Internet. The figures have since dropped as organizations continue to apply the fixes.

The cloud security subsidiary has observed the following post-exploitation activities following the abuse of the two flaws -

• Uploading a malicious plugin
• Enumerating users and harvesting admin usernames and email addresses
• Performing local file inclusion (LFI) attacks to target database credentials and authentication keys for exfiltration
• Accessing the admin panel and successfully authenticating themselves
• Uploading a bare-bones PHP web shell that facilitates remote code execution

"We've also observed high-volume scanning activity without subsequent post-exploitation, suggesting opportunistic mass-scanning campaigns seeking to identify vulnerable targets alongside legitimate security scanning activity," Wiz researchers Shahar Dorfman and Gili Tikochinski said. "We have yet to identify lateral movement or data exfiltration, but we continue to monitor and investigate."

Also observed as part of the activity is a 150 KB web shell that's disguised as a legitimate WordPress security plugin called CMSmap. It acts as a "full-featured attack platform" supporting file management, database access, port scanning, batch code injection, and multiple privilege escalation modules, including MySQL UDF exploitation.

WatchTowr also said attackers have begun to spray the Internet in an indiscriminate fashion following the release of a public exploit, with its honeypots registering "tens of thousands of exploitation attempts."

More than 100 backdoor administrator accounts are said to have been created following exploitation, allowing the attackers to deploy fake WordPress plugins to gain code execution or download secondary tools to further compromise the system. In at least one case, a threat actor has been observed repeatedly attempting to install Overlord RAT, a Golang-based remote access trojan.

Defenders are recommended to inspect their WordPress instances for new administrator accounts, malicious plugins, or other suspicious files, regardless of whether they've been patched, to completely root out the threat.

from The Hacker News https://ift.tt/VtjELpk
via IFTTT

Critical ServiceNow AI Platform Flaw Exploited for Unauthenticated Code Execution

Threat actors are now exploiting a recently disclosed critical security flaw impacting ServiceNow AI Platform, according to Defused Cyber.

In a post shared on X, the threat intelligence firm said it's observing in-the-wild exploitation of CVE-2026-6875 (CVSS score: 9.5), a sandbox escape vulnerability that could allow an unauthenticated user to run arbitrary code.

Patches for the flaw were released by ServiceNow throughout June in the following versions -

• Brazil EA and Brazil GA
• Australia Patch 2
• Zurich Patch 7b and Zurich Patch 9
• Yokohama Patch 12 Hot Fix 1b and Yokohama Patch 13

Searchlight Cyber, which disclosed additional technical specifics, said it reported the issue on April 1, 2026, adding it allows a complete compromise of the ServiceNow instance as well as all connected proxy servers.

Besides rolling out a fix, ServiceNow is "enhancing instance security by severely restricting the type of code that can run in sandbox contexts," security researcher Adam Kues noted.

According to Defused, the exploitation efforts target the same pre-authentication endpoint ("/assessment_thanks.do") using HTTP POST requests, although the sandbox-escape gadget leads to the same code execution primitive by a different route documented in the proof-of-concept (PoC) exploit.

In light of active exploitation, customers of self-hosted versions are advised to apply the fixes, if not already, to counter the threat.

from The Hacker News https://ift.tt/d7FZiPb
via IFTTT

⚡ Weekly Recap: WordPress RCE, SonicWall 0-Days, AI Service Attacks, SharePoint 0-Day and More

A single request should not be able to do this much. But this week, small inputs led to code execution, memory loss, stolen keys, and disabled security tools.

The paths were often simple: exposed systems, weak checks, old drivers, fake prompts, and public code used for malware delivery. Some bugs were new. Others were already being used before defenders had time to patch.

Here is the full recap of what broke, what was exploited, and what needs attention now.

⚡ Threat of the Week

New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code - Searchlight Cyber disclosed a pre-authenticated remote code execution vulnerability in WordPress Core that can be exploited anonymously on a standard WordPress installation, without requiring any plugins or other special conditions. It is a combination of CVE-2026-63030 (REST API batch-route confusion) and CVE-2026-60137 (SQL injection in WordPress core) that can be chained to turn an anonymous request into code execution. watchTowr said it's already seeing proof-of-concept (PoC) exploits in circulation and that it's beginning to see the first signs of in-the-wild exploitation. "This is going to hurt," watchTowr CEO Benjamin Harris said. "WordPress runs on hundreds of millions of websites globally. Some of those will be auto-patched by their hosting providers, but plenty will not, and that is where the damage will be done. Our advice is simple: patch as fast as you possibly can, and do not stop there. Put the controls and investigations in place to determine whether an attacker got there first and to detect and remove any backdoors that may already have been dropped before you patched." The cybersecurity company said it's the latest example of vulnerabilities being surfaced by AI-assisted tooling and how the technology is being abused by attackers to weaponize them.

AI Broke Vulnerability Management. Here Is the CISO Case

The AI security job market is no longer theoretical. SANS tracked hiring across 10 specific roles and mapped verified job data, salary ranges, and the skills required to get there. The three-tier framework gives your team a clear view of which roles to prioritize now and which to develop toward.

Download Now ➝

🔔 Top News

• SonicWall SMA Zero-Days Exploited as 0-Days - A previously undocumented threat actor codenamed UTA0533 has been attributed to the exploitation of recently disclosed SonicWall Secure Mobile Access (SMA) 1000 series VPN appliances as zero-days prior to their public disclosure since June 22, 2026. The discovery was made following an incident response investigation initiated earlier this month. The impacted organization has not been identified. "This threat actor was observed using multiple zero-day exploits, malware designed specifically for SonicWall SMA VPN appliances, as well as other attacker tradecraft," Volexity said. The vulnerabilities in question are CVE-2026-15409 (CVSS score: 10.0) and CVE-2026-15410 (CVSS score: 7.2), both of which could be chained to facilitate arbitrary command execution and take over susceptible devices. Patches for both vulnerabilities were released by SonicWall last week.
• DoS Flaw in OpenSSL - The Okta Red Team disclosed details of HollowByte, a denial-of-service (DoS) flaw in OpenSSL. "By sending a malicious payload of just 11 bytes, a remote, unauthenticated attacker can force a server to allocate disproportionate chunks of memory before any security handshake even begins," Okta said. Put differently, an unauthenticated attacker -- through 11 bytes of carefully crafted data -- can convince OpenSSL to reserve up to 128 KB of heap memory for a handshake message that never actually arrives, causing a server to exhaust available RAM and trigger a DoS condition. The OpenSSL team resolved the issue in versions 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. "Instead of trusting the header outright, OpenSSL now grows the buffer only as bytes actually land on the wire. A claim with no follow-through now costs the server nothing," Okta said.
• CISA Adds New SharePoint RCE Zero-Day to KEV Catalog - The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a newly patched security flaw impacting Microsoft SharePoint Server to its Known Exploited Vulnerabilities (KEV) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the fixes by July 19, 2026. The vulnerability, CVE-2026-58644 (CVSS score: 9.8), is a critical deserialization of untrusted data vulnerability that allows an unauthorized attacker to execute arbitrary code. Patches for the flaw have been released as part of the Patch Tuesday updates released on July 14, 2026. Microsoft revised its bulletin to clarify that CVE-2026-58644 has been exploited in the wild, meaning the shortcoming was weaponized as a zero-day prior to the fixes becoming available. The development came as Microsoft shipped its largest Patch Tuesday on record, addressing 622 vulnerabilities.
• OkoBot Malware Framework Infects Windows to Phish Crypto Seed Phrases - A new malware framework called OkoBot is designed to capture the contents of cryptocurrency wallet windows. OkoBot is an updated version of TookPS, which is a downloader for retrieving malicious commands and scripts from attacker-controlled servers to further propagate attacks, including a Python-based infostealer and a remote access trojan called TeviRAT. "This campaign differs from previous activity in that it uses a new framework to deliver all malicious modules and orchestrate them via an SSH tunnel," Kaspersky said. "In total, the framework includes more than 20 malicious payloads and implants, covering a wide variety of functions. At the time of writing, the threat remains active." The infection chain makes use of ClickFix and malware distributed through GitHub that masquerades as legitimate software for initial access. It also comes with a web browser extensions loader to deliver Rilide, a browser-based stealer, as well as inject an implant into Trezor Suite, Ledger Wallet, and Ledger Live processes to collect seed phrases, log keystrokes and clipboard content, take screenshots, and capture keystrokes and the video stream of the target application's window using the OkoSpyware module. Hundreds of victims of the OkoBot campaign have been detected in more than 25 countries, with the highest concentration in Brazil, Vietnam, Canada, Mexico, and Türkiye. The activity remains unattributed.
• NadMesh Scans Exposed AI Services for Cloud Keys and Kubernetes Tokens - A new Go botnet called NadMesh has been observed hunting for exposed AI services related to ComfyUI, Ollama, n8n, Open WebUI, Langflow, and Gradio to steal AWS keys and Kubernetes tokens. "It folds scanning, exploitation, and credential/AI-service intelligence harvesting into a single autonomous platform," QiAnXin XLab said. "On the victim, the bot agent establishes persistence along three independent paths: an SSH public-key backdoor (.ssh/authorized_keys), persistence files in multiple locations (/dev/shm/.a, /var/tmp/.a, /tmp/.a), and hidden cron watchdogs (/etc/cron.d/.sys_monitor, /etc/cron.d/.s)."

‎️🔥 Trending CVEs

Bugs drop weekly, and the gap between a patch and an exploit is shrinking fast. These are the heavy hitters for the week: high-severity, widely used, or already being poked at in the wild.

Check the list, patch what you have, and hit the ones marked urgent first - CVE-2026-63030, CVE-2026-60137 (WordPress Core), CVE-2026-58644, CVE-2026-56164 (Microsoft SharePoint Server), CVE-2026-56155 (Microsoft Active Directory Federation Services), CVE-2026-53412 (Zoom Desktop Client for Windows and Zoom VDI Client for Windows), CVE-2026-44747, CVE-2026-27690, CVE-2026-44761 (SAP), CVE-2026-57219, CVE-2026-57221 (RabbitMQ), CVE-2026-59208, CVE-2026-54305 (n8n), CVE-2026-60105 (Monsta FTP), CVE-2026-14960, CVE-2026-14961 (tdeio64.sys driver), CVE-2026-33894, CVE-2026-33895 (Digital Bazaar node-forge), CVE-2026-6875 (ServiceNow AI Platform), CVE-2026-42533, CVE-2026-60005, CVE-2026-56434 (F5 NGINX Plus and NGINX Open Source), CVE-2026-20296, CVE-2026-20297 (Splunk Enterprise), CVE-2026-15265 (Tenable Agent), CVE-2026-6423 (ESET Inspect Connector), CVE-2026-15053 (Tanium Server), CVE-2026-44909, CVE-2026-59173, CVE-2026-59762 (HTTP/2 server implementations), CVE-2026-14890 (SGLang), CVE-2026-14266 (7-Zip), CVE-2026-59084 (Apache Tomcat), CVE-2026-15682 (AnyDesk), and CVE-2026-54523 (Kyverno).

🎥 Cybersecurity Webinars

• Your AI Agent Has Credentials. Can You Stop It When It Goes Rogue? Hands-on testing of OpenClaw shows how agentic AI can expose secrets, bypass safety controls, and create a powerful new attack surface. Join Okta Threat Intelligence Director Jeremy Kirk to examine how attackers are abusing AI agents and learn practical ways to control access, enforce least privilege, detect shadow AI, and shut down risky agents before they cause damage.
• When AI Ships 50× More Code, Human Review Stops Scaling → AI-assisted development is pushing code production beyond what traditional security reviews and CVE-driven remediation can handle. This webinar gives security leaders a practical framework for governing the expanding attack surface, building secure-by-default controls, and enabling teams to develop at machine speed without surrendering control of software risk.

📰 Around the Cyber World

• New Campaign Delivers Remcos RAT - A new malware distribution campaign has abused the credibility of government institutions to increase the likelihood of infection success. The activity targets Indian businesses and taxpayers using Goods and Services Tax (GST)-related themes to distribute malware. "The threat actors impersonated legitimate government departments and distributed malicious emails disguised as official notifications related to taxation, refunds, compliance requirements, and regulatory matters," Seqrite Labs said. "The threat actors employ convincing documents and filenames that closely resemble official GST notifications, making it difficult for recipients to distinguish malicious content from legitimate government correspondence." The end goal is to deploy Remcos RAT and steal sensitive information.
• India's Kudankulam Nuclear Power Plant Suffers a Data Leak - The Kudankulam Nuclear Power Plant located in the Indian state of Tamil Nadu suffered an accidental exposure after Reliance Infra (RPOWER) got hit by a ransomware group called World Leaks, a spin-off of Hunters International, which, in turn, is another variant of the Hive ransomware family. The leak consists of 18,997 files, totalling 14.3GB of data, per security researcher Rakesh Krishnan. They contain purported blueprints for the ventilation and cooling systems used in Unit 3 and Unit 4, along with a complete floor layout of a "common control room". It's assessed that Reliance Infra was not impacted directly, but rather through a third-party vendor named Yotta.
• Blind Eagle Shows No Signs of Stopping - Nearly a year after Blind Eagle's activities were documented, a new report from LevelBlue has found the threat actor to be active, moving part of its VBScript delivery infrastructure onto the Russian bulletproof hosting provider Proton66 as of June 2025. The group has also devised a bespoke string-obfuscation scheme, a RunPE loader built entirely on a bare AutoIt3 interpreter, and an upgraded version of AsyncRAT that introduces Windows Notification Facility (WNF) process injection, a custom Base28 payload encoding, a full Hidden VNC (HVNC) banking-fraud module with browser profile cloning, and a Chrome App-Bound Encryption (ABE) bypass, per LevelBlue.
• Qilin Ransomware Use of EDR Killer - Qilin ransomware operations have been observed adopting aggressive, kernel-level defense evasion to blind and disable endpoint security products before its main ransomware payload is executed on a victim's network. The EDR killer, packed via the Shanya packer, is sold on illicit marketplaces for $2,000. "The EDR killer compares the returned locale to a known locale blacklist to avoid attacking any Commonwealth of Independent States (CIS) countries such as Russia and Belarus," Flashpoint said. "The EDR killer then writes a vulnerable driver to disk and loads this driver via Service Manager. This driver is the ThrottleStop driver from TechPowerUp LLC's free and legitimate application of the same name, used to bypass CPU throttling. However, the driver suffers from a vulnerability, allowing the malware to map physical memory to kernel-mode virtual memory to perform direct kernel read and write operations." Also put to use is a custom Rust-written loader that performs reflective Portable Executable (PE) loading of the ransomware payload.
• DefiTuna Suffers a Security Incident - DeFiTuna, an Automated Market Maker (AMM) on the Solana blockchain, was exploited on July 16, 2026, for $569,601 USDC. "The attackers created a highly illiquid TUNA/USDC pool and used it as the destination for borrowed USDC routed through Jupiter," CertiK said. "Because the swap returned only a negligible amount of TUNA, DeFiTuna's value calculation rounded the position's total assets down to zero. The protocol then incorrectly treated the position as healthy, allowing the attackers to bypass the solvency check and withdraw the USDC through attacker-controlled liquidity positions."
• Next.js Opts for Scheduled Security Releases - Vercel announced that Next.js is adopting a formal security release program, replacing ad-hoc patches for security fixes following a surge in AI-assisted vulnerability discovery. "This kind of scheduled, pre-announced security release has become standard practice for major open source projects, and we think it's the right model for Next.js at its current scale," Vercel said. "Here's what you can expect going forward: roughly once a month, we'll publish advance notice of upcoming security releases. Each announcement will include the expected release timeline and the highest anticipated severity among the vulnerabilities it covers. This lead time lets you plan your upgrades, and it lets us coordinate with hosting providers and other platform partners to deploy mitigations, such as firewall rules, that help protect applications that haven't been patched yet."
• Disguised Gambling Apps Target Brazil - A new analysis from 9to5Mac has revealed more than 60 "jacket apps" on the App Store that are disguised as simple games and utilities that become online betting platforms when accessed from Brazilian IP addresses. Most of the apps are published by developer accounts with only a single App Store listing, with further investigation linking them to a "public GitHub repository containing instructions for a Cursor agent to create simple, vibe-coded apps that serve as fronts for the betting platforms."
• Ransomware Stats for Q2 2026 - The Gentlemen has become the most active ransomware group for Q2 2026, claiming 300 victims, surging past Qilin (289), DragonForce, Akira, and LockBit. Another group named Deadlock resurfaced after 11 months of silence with 75 June victims. In all, the top 11 tracked groups accounted for 1,368 of Q2's victim claims across 99 countries. "What sets The Gentlemen apart is its packaging, where affiliates receive ready-made tools that ship and update faster than most competing programs," ReliaQuest said.
• 2 Members of Chinese Money Laundering Network Charged with Laundering $43M in Investment Fraud - The U.S. Justice Department unsealed charges against a New York man and woman for conspiracy to launder money derived from cyber investment fraud scams. "Between 2020 and 2022, Zhuoying Chen, 27, of Brooklyn, New York, and Haojie Zhang, 38, of Queens, New York, managed a network of more than a dozen individuals based in Queens and Brooklyn, who opened 140 bank accounts in the name of approximately 45 shell companies to launder at least $43 million in proceeds of investment scams," the department said. "Then, Chen and Zhang allegedly conspired with China-based co-conspirators to transfer the funds involved in the fraud schemes abroad. The fraud schemes consist of perpetrators contacting victims via messaging services or social media applications. The perpetrators would initiate relationships with the victims and gain their trust, convincing victims to send money for lucrative investment opportunities. The perpetrators would show the victims fake profits on the purported investment and encourage the victims to invest more. The perpetrators would then steal the victim's funds."
• U.S. Cyber Agency Uses Mythos to Audit Government Code - Reuters reported that the U.S. Cybersecurity and Infrastructure Security Agency (CISA) is using Anthropic's AI model Mythos to audit government software for defects that could potentially offer a pathway for foreign spies and cybercriminals, citing three people familiar with the matter.

• VisionSec → It is an open-source, self-hosted threat intelligence platform that combines domain monitoring, phishing detection, exposed-service scanning, GitHub secret discovery, breach checks, email security assessments, and Telegram alerts in a modular Docker-based deployment. The project remains at an early stage, with no published releases at the time of writing.
• owLSM → It is an open-source Linux security agent that uses eBPF LSM to run stateful Sigma rules inside the kernel, block malicious activity, correlate events across multiple probes, and provide detailed context for security monitoring and response.

Disclaimer: This is strictly for research and learning. It hasn't been through a formal security audit, so don't just blindly drop it into production. Read the code, break it in a sandbox first, and make sure whatever you're doing stays on the right side of the law.

Conclusion

That is the week: exposed systems, weak checks, old tools, and attackers moving faster than patch cycles.

Review what applies, fix the obvious gaps first, and assume anything public has already been tested.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/XlDuUmW
via IFTTT

The Agentic SOC: Transforming Data into Defensive Velocity

Security Operations Centers (SOCs) are currently confronting scalability challenges on two fronts: structural and cognitive. The day-to-day reality of modern defensive operations is stark: an analyst frequently begins a shift facing a queue deeply saturated with unvetted alerts. To process a single event, the analyst must open the alert, pivot to a secondary console to complete an investigation, manually enrich an IP address, copy a file hash into a third interface, and cross-reference an asset inventory that may not have been updated in months. Following this, they must author and refine queries, waiting for overloaded databases to return historical context.

The actual work of assessing the investigation’s results and moving to decision-making and action has not even begun. This is the administrative burden of the modern SOC. The true threats are not just those that attempt to bypass defenses, but the critical operational hours lost before an active mitigation attempt is even initiated. While analysts are highly trained professionals, the relentless requirement to perform manual data aggregation inevitably leads to exhaustion.

Misdiagnosing the Bottleneck: The Upstream Data Problem

Threat actors operate at machine speed, utilizing automation to pivot laterally across networks in a matter of seconds, frequently disappearing before defensive teams can even log into their terminals. Expecting human defenders to counter automated threat vectors by manually aggregating bad data is an architectural failure.

Every SOC inherits a highly fragmented data ecosystem. Telemetry is continuously generated by diverse sources, including firewalls, cloud workloads, identity providers, endpoint sensors, and legacy systems. This telemetry arrives in disparate dialects, varying formats, and highly inconsistent levels of fidelity. Before AI tools can accurately reason about a potential threat, or an analyst can initiate a logical investigation and run a playbook response, this raw telemetry must be synthesized.

Historically, organizations analysts take on these complex synthesis processes, manually normalizing data points across different vendor schemas. This represents a key misallocation of human intelligence. The asymmetry in modern security operations is not merely a discrepancy in speed; it is an imbalance in how security teams are forced to allocate their finite time. When operators spend the majority of their shifts wrangling data instead of actively investigating threats, the foundation of the SOC itself is inadequate. To achieve defensive velocity, organizations must recognize that fixing the data foundation is the mandatory prerequisite for improving all downstream security functions.

Architecting the Data Foundation with Singularity AI Data Pipelines

Addressing the upstream data problem requires the implementation of advanced data pipelines capable of resolving enterprise data chaos before it impacts the detection engine. Frameworks such as SentinelOne’s® Singularity AI Data Pipelines serve as this foundational layer, engineered to ingest telemetry from every source and in every format without requiring months-long integration projects or heavy manual engineering.

Modern pipelines utilize AI to normalize raw telemetry into standardized formats, specifically aligning with the Open Cybersecurity Schema Framework (OCSF). This structural alignment transforms fragmented logs into structured data that is immediately actionable. It eliminates the need for analysts to construct complex regular expressions during critical incidents simply to reconcile how two different software vendors format data, such as usernames or a timestamp.

Efficient data ingestion also requires dynamic, in-flight optimization. Not all telemetry possesses the same analytical value, and storing all generated logs in highly indexed, expensive storage tiers is financially and operationally untenable. Data pipelines optimize data streams by filtering out extraneous noise, trimming excess volume, and routing specific logs based on dynamic criteria. High-value security events are routed and indexed for rapid search retrieval, while lower-priority compliance or operational logs are routed to more cost-effective tiered storage. The result is a substantial reduction in infrastructure costs, a higher signal-to-noise ratio, and a structured data foundation that is completely prepared the moment an investigation is required.

When underlying data pipelines automatically enrich that log with identity and asset information, revealing (for example) that a specific financial director’s laptop in a remote office is communicating with a known botnet, the output transitions from a raw data point into a definitive starting point. Crucially, this enrichment occurs systematically before the human operator ever interacts with the alert. Solving this data problem end-to-end is a primary reason SentinelOne was recognized in the IDC MarketScape for AI SIEM.

Accelerating Detection via Singularity AI SIEM

When a clean, structured data foundation is properly established, the performance of downstream security tools accelerates. Modern detection engines, such as the Singularity AI SIEM, leverage indexless architectures to manage enterprise-scale telemetry. Because the data is normalized and optimized prior to ingestion, these platforms can execute petabyte-scale queries with minimal latency, ensuring investigative results are delivered before the analyst’s attention wanes.

Within this architecture, detection logic is executed continuously against a stream of clean, correlated telemetry. This transforms an ocean of disparate event logs into readable, centralized dashboards that provide immediate situational awareness. The quantitative benefits of this approach are substantial. With AI SIEM, organizations are already executing their queries 70% faster. Adding AI Data Pipelines further augments this workstream, providing cleaner data for AI to run at optimal efficiency. These improvements represent the direct result of ensuring that the data arriving at the SIEM is inherently fit for purpose.

AI SIEM remains a single, comprehensive SKU with customers automatically receiving integrated pipeline functionality for everyday data optimization rather than treating it as a premium add-on. For every unit of paid Data Ingest capacity, customers can process twice that volume through Data Pipelines. A customer with 500 GB/day SIEM entitlement can push 1 TB/day through the pipeline at no additional cost.

Transitioning to Agentic Reasoning Layers with Purple AI

The establishment of a structured data pipeline unlocks the capability for true agentic reasoning within the SOC. Unlike traditional rule-based automation, which executes static responses to predefined triggers, technologies like SentinelOne’s Purple AI operate as a dynamic investigative layer.

When an initial alert is generated, an agentic reasoning system does not simply pause and wait for human triage. It autonomously launches an investigation, comprehensively maps the potential blast radius of the incident, and synthesizes a clear, logical recommendation for containment. Then, the analyst logs into the console and is presented with a fully formed situational briefing rather than a blank investigation screen.

More importantly, an agentic AI layer possesses the capacity to evaluate broader adversarial campaigns rather than isolated security events. In isolation, a minor registry key modification, a singular file write, or a brief outbound network connection may not meet the threshold for a critical alert. Legacy security tools often fail to connect these disparate, low-signal events. However, Purple AI can assemble these seemingly unrelated activities into a cohesive narrative, exposing the overarching strategy of the attacker before a major breach occurs.

This level of autonomous intelligence is strictly dependent on the underlying architecture. Advanced AI algorithms cannot derive accurate conclusions from unparsed, low-quality telemetry. The analytical integrity of the agentic layer is entirely contingent on the principle of data quality; systems like Purple AI require clean, structured data to function effectively, avoiding the fundamental issue of “garbage in, garbage out”.

Governed Hyperautomation and the Human-in-the-Loop

The final component of a modernized, agentic SOC is the deployment of Hyperautomation to execute defensive responses. To counter threats effectively, organizations must deploy automated workflows capable of executing decisions at machine speed. These no-code workflows can be configured to trigger autonomously based on AI triage verdicts, the disclosure of new high-severity vulnerabilities, or specific incoming alerts. By automating the mitigation phase, the SOC evolves from an environment strictly dedicated to passive observation into a dynamic system that actively neutralizes threats.

However, the implementation of automated response mechanisms must be rigorously governed. Executing changes to enterprise infrastructure carries inherent risk. To mitigate this, automated workflows must integrate critical approval steps, ensuring that highly consequential actions are paused until human authorization is provided. The analyst retains the ultimate authority, defining the precise parameters of what processes may run automatically and what workflows require manual judgment.

Redefining the Analyst Mandate via Autonomous Security Intelligence

The strategic objective of integrating data pipelines, agentic reasoning, and Hyperautomation is not the removal of the human operator. Instead, the overarching goal is the restoration of the analyst’s primary function: exercising expert judgment.

By offloading repetitive tasks to technological systems, organizations systematically remove operational friction. The data layer filters out irrelevant noise, allowing the analyst to clearly see the threat. The AI investigation layer removes the administrative grind of data collection, allowing the analyst to focus purely on analytical thinking. Finally, the automated response layer eliminates procedural delays, ensuring the analyst’s decisions are executed rapidly enough to matter. This creates an intelligence fabric, known as Autonomous Security Intelligence (ASI), where data, investigation, and response function concurrently as a single, unified system.

Under this model, the operational output of a single analyst is exponentially multiplied, allowing one unburdened professional to accomplish the work of ten while still owning every critical decision. While the alert queue will perpetually require attention, the fundamental nature of the work fundamentally changes. The timeline of a manual initial triage to active investigation compresses from a multi-hour ordeal into a matter of minutes. The data arrives clean, the investigation runs automatically, and the response mechanisms are prepared. The hours previously consumed by administrative waiting are directly reallocated to strategic decision-making.

Conclusion

When defensive systems are finally architected to operate at the speed of the modern threat landscape, the role of the human operator transforms. Analysts are no longer forced to act as passive passengers, grateful to be carried by fragmented tools. They are elevated to the role of pilots, operating with full situational awareness, retaining their judgment, and actively directing the defensive posture of the organization. This is the paradigm of the agentic SOC, and it is entirely predicated on the foundation of clean, structured data.

Contact us today to learn more about how SentinelOne is leading the way forward with Agentic SOC.

 

from SentinelOne https://ift.tt/DLSAEdZ
via IFTTT

Mythos Didn't Break Your Security Program. Your Exposure Window Could.

The industry spent the initial months after Anthropic's April 7 Mythos reveal focused on volume. How many new CVEs would Mythos add to an already overloaded pipeline? How quickly would the flood of AI-driven discovery overwhelm triage capabilities? How long would it take adversaries to weaponize Mythos findings at scale? Those questions were and remain valid. Yet they all stop short of addressing the single metric that determines whether any of those vulnerabilities actually lead to a breach: the exposure window.

The exposure window - the gap between the moment a vulnerability becomes exploitable and the moment your team fixes it - is the time an attacker has to do actual damage. That window is currently open far too wide. In 2025, the average eCrime breakout time dropped to 29 minutes. Even PCI DSS - the strictest compliance framework in the industry - allows 30 days to remediate a critical vulnerability. That's a 1,000-to-1 gap between how fast attackers move and how fast organizations are expected to respond. And the stick propping this exposure window open? Mobilization - the ownership, remediation, and organizational complexity that lowers response times and raises risk.

In this article, I'll walk through why the exposure window is now the metric that matters most, what keeps it open, and how AI-driven discovery is forcing proactive security teams to adopt the speed-based metrics that SOC teams have used for years.

Mythos Didn't Create the Exposure Window. It Widened It.

The vulnerability management model was already showing cracks before Mythos came on the scene. 48,185 CVEs were disclosed in 2025 - a 22% jump over 2024. Most security teams were already drowning in their remediation backlog. And current projections are that 66,000 new CVEs will be listed in 2026. Often, every one of those CVEs ends up in the same remediation pipeline - subject to manual approvals, fragmented ownership, and change windows that move at the pace of enterprise IT - not at the pace of attackers.

Gartner's CTEM framework defines five stages: scoping, discovery, prioritization, validation, and mobilization. The first three stages now run at machine speed. Validation - confirming that your controls actually stop real threats - has improved as platforms have automated attack path testing. Yet mobilization still runs at organizational speed.

Recent policy moves acknowledge the disparity. Notably, CISA's BOD 26-04 shifts federal agencies from CVSS-first patching toward exploitability and asset context (which is what CTEM has called for all along). But this directive still addresses only which vulnerabilities to fix first. It does not address how fast organizations can mobilize to execute the fix. Meaning, it still leaves the exposure window wide open.

Why Mobilization Is Where Programs Break

The gap between knowing which vulnerability to fix and actually fixing it is a mobilization problem. The security team identifies the exposure, and a different team - one with its own priorities, its own change windows, its own approval chains - has to remediate it. That handoff is the soft underbelly of most CTEM programs. Enterprise remediation processes were built for a pipeline that moves at human speed, but every stage upstream of mobilization no longer does.

According to recent research, high and critical application vulnerabilities take an average of 55 days to remediate, and nearly half of enterprise vulnerabilities remain unpatched after a full year. Most organizations still do not prioritize remediation based on exploitability and business impact, in any case. And legacy systems, OT environments, and production infrastructure can have a serious business impact when they go offline - so fixes tend to wait. Further, identity exposures like excessive privileges and cached credentials don't even have a patch to apply. Many findings simply land in the queue with no single team responsible for resolving them.

The point is that the exposure window stays open because the organizational machinery between "fix this" and "fixed" takes weeks or months to turn, while attackers need just minutes. Which begs the question: how long can proactive security teams keep measuring success on a different clock than attackers?

Proactive Teams Now Operate on Reactive Timelines

Security organizations have traditionally split into two operational modes. SOC teams - the reactive side - track dwell time, mean time to respond, and containment speed. Their job is to limit damage from threats already inside the environment. VM teams, cloud security teams, and network security teams - the proactive side - track patch coverage by severity level or time to fix misconfigurations. Their job is to reduce exposure before an attacker arrives.

The thing is, AI-driven discovery essentially puts both teams on the same stopwatch.

When vulnerabilities move from disclosure to weaponization in hours and breakout time is measured in minutes, a quarterly patch rate of 90% means nothing if critical assets sat exploitable for weeks while those patches waited in the queue. Proactive teams now need the same speed-based metrics the SOC has always used - because no remediation process can outrun a 29-minute breakout time on its own.

Teams need to accept that the exposure window will never fully close. Rather, we need to ask ourselves how far we can close it, and when an attacker moves through the gap, how many critical assets can they reach?

Shrinking the Blast Radius

That reachable set of assets - the blast radius - is what determines actual business risk. Since no organization can close every exposure at the speed attackers move, priority needs to shift to the paths that connect exploitable exposures to critical assets. The 2026 Verizon DBIR makes this case for attack path analysis - with the goal of making the blast radius visible.

Not every exposure leads somewhere dangerous. Attack path analysis shows which exposures open routes to critical assets and which ones are simply dead-ends. This narrows the scope of mobilization - from an unfinishable backlog to a finite set of paths. And once teams start tracking how long critical assets stay reachable, remediation speed becomes a business risk metric. Mobilization stops holding the exposure window open and starts closing it.

Mythos didn't break your security program. Your exposure window might - if you let mobilization keep propping it open.

Note: This article was thoughtfully written and contributed for our audience by Ryan Blanchard, Director of Product Marketing, XM Cyber.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/UeH6nN8
via IFTTT