Every investigation starts the same way — re-explaining your environment, your log sources, your detection standards, before you can even get to the actual analysis. Multiply that setup tax across every new chat you open for the same investigation, and you’re spending more time re-briefing the AI than hunting threats.

Projects solves this. Available within Agentic Threat Research — the AI-assisted workspace in Prime Architect for detection engineering and threat research — Projects let you group multiple chats under a single shared context, so you only have to set the stage once. Define your data schema, log sources, detection structure, and expected output up front, and every chat in that project automatically inherits it. No more re-pasting the same background into every new session — the AI already knows how your environment works before you type your first question.

Think of a project as a workspace built around a specific investigation focus — a threat campaign, your or a customer environment, a detection engineering initiative, an ongoing incident. Everything the AI needs to reason correctly about that focus lives in one place, and every chat inside it starts from that same, fully-briefed baseline. Projects sit right in the left panel of Agentic Threat Research alongside your regular chats, and everything you already rely on there — custom prompts as well as the built-in Agentic AI tools — works the same way inside a project, just with your context already applied.

Contact Sales

Why It Matters

• Consistency across your own investigations. Every chat you open inside a project starts from the same baseline context, so your results stay comparable and repeatable across sessions, instead of depending on what you happened to type into the prompt that day.
• Faster investigations. Skip the setup tax entirely. Open a new chat and get straight to the analysis — the context is already loaded, so the AI can go from question to answer instead of question to clarifying-question.
• Institutional knowledge, built in. Upload your internal playbooks, incident reports, environment documentation, and other security-related reference materials so the AI reasons with your organization’s actual standards and history, not generic assumptions about how a SOC should work.
• Precision by design. Set rules once — clarify assumptions before acting, require precise technical language, suggest tuning ideas for noisy detections — and every chat in the project follows them automatically, without you having to repeat yourself.
• A dedicated workspace per investigation. Keep separate projects for separate focuses — a threat campaign, your or a customer environment, a detection engineering initiative — so the context loaded into each one is always exactly what that investigation needs, without unrelated work affecting it.

A Quick Example

Say you’re running a project focused on lateral movement detection. You attach your data schema so the AI understands your field naming conventions, list out your log sources (EDR, VPN, identity provider, and firewall logs) so it knows what evidence is actually available, and upload your detection structure and expected output template so every finding comes back in the same format you use for triage. You also drop in a couple of relevant internal playbooks and prior incident reports covering similar activity. From that point forward, every new chat you open in that project can answer questions like “does this authentication pattern match known lateral movement TTPs in our environment?” grounded in your actual data model and your own case history — not a generic response — without you having to re-explain any of it.

Getting Started

1. Create a project. In Prime Architect, go to the Agentic Threat Research mode, select Projects in the left panel, and then select Create Project. Give it a name.

2. Define the shared context. Pick either or both:

• Instructions: Click the pencil icon in the Instructions section and write a prompt describing how the AI should behave in this project — for example, your data schema, log source details, detection structure and expected output format, or key rules like clarifying assumptions and using precise technical language. Select Save. You can revisit and edit this anytime via the same pencil icon.

• Resources: Click the plus (+) icon in the Resources section, select Upload Files, and attach your reference material — playbooks, incident reports, environment docs, or other security references. You can upload up to 5 files, each up to 15 MB and 500k tokens. Supported formats: PDF, TXT, CSV, JSON, PNG, JPG/JPEG (PDFs up to 1,000 pages). 

Everything you add here applies automatically to every chat in the project.

3. Start working. Open the project and start a new chat — it inherits the context immediately, no extra steps required. All chats you create within the project are grouped together and available under the chat panel, so your investigation history stays organized in one view instead of scattered across a general chat list.

4. Keep it organized. As a project grows, you can rename or delete individual chats at any time — just click the three-dot menu next to a chat and select the option you need. This makes it easy to keep active investigations clearly labeled and archive ones that are closed out, without losing the shared context that the rest of the project still relies on.

Set the context once. Investigate faster, every time after.

The post Projects in Agentic Threat Research: Context That Sticks appeared first on SOC Prime.

Security teams are drowning in threat reports. Every week brings a new advisory, a new vendor write-up, a new blog post describing the latest campaign — and every one of them demands hours of manual reading, cross-referencing, and translation into something your SOC can actually act on. Deep Threat Research changes that equation entirely.

Deep Threat Research is an agentic AI tool available within Agentic Threat Research mode in Prime Architect. It takes any threat report and instantly transforms it into structured, decision-ready threat intelligence — complete with a clear threat summary, precise MITRE ATT&CK mappings, and a full set of interactive visualizations that show exactly how an adversary operates. What used to take an analyst hours of manual triage now happens in minutes, freeing your team to focus on what matters most: threat detection and threat mitigation.

What Deep Threat Research Solves

Every threat report contains value, but that value is locked inside dense paragraphs of prose. Deep Threat Research unlocks it automatically. It reads the report the way your most experienced analyst would — extracting the adversary’s tactics, techniques, and procedures, identifying relevant indicators, and mapping everything against the MITRE ATT&CK framework — then hands you a complete intelligence package: investigation guidance, mitigation recommendations, response actions, associated threat actors, and even AI-generated detection rules ready for deployment.

Instead of starting from a blank page, your team starts from a fully-formed picture of the threat: who’s behind it, how it moves, what it touches, and how to stop it.

Contact Sales

What You Get

Once an analysis completes, results are generated and appear one after another. Some sections are ready to read right away, while others display as tiles you simply click to open and explore in more detail — just scroll down to move through the full analysis. Overall, Deep Threat Research organizes its findings into clear, digestible sections:

• Summary – the essential facts of the threat, distilled from the report
• Investigation – guided next steps for analysts
• Mitigation – best-practice actions to reduce impact

• Response – recommended steps once malicious activity is confirmed
• Actors – the threat actors tied to the activity
• MITRE ATT&CK Techniques – the specific behaviors and techniques adversaries used, mapped directly to the framework
• Detections – existing SOC Prime Platform detections plus new AI-generated rules, ready to copy, translate into your SIEM’s language, validate, or save straight to your repository

• Simulation – ready-made simulations of the malicious activity for testing your defenses

On top of that, four interactive visualizations bring the intelligence to life:

• Attack Flow – the adversary’s full attack sequence based on MITRE ATT&CK, viewable as a diagram or matrix and exportable as MMD

• Cyber Kill Chain – maps the threat across all seven Lockheed Martin stages, from Reconnaissance to Actions on Objectives, so you can spot detection opportunities at every phase

• Pyramid of Pain – breaks down every extracted indicator into six tiers, from Hash Values and IP Addresses up through Domain Names, Network/Host Artifacts, Tools, and TTPs, so you can see at a glance how resilient your detection coverage really is

• Diamond Model – connects the four pillars of any intrusion — Adversary, Capability, Victim, and Infrastructure — and shows how they link together

Getting Started

Getting from a raw report to full threat intelligence takes just a few steps:

1. Open Prime Architect and select the Agentic Threat Research mode.
2. Click Code Editor in the upper-right corner and paste in the text of your threat report. 
3. Select Analyze.

4. Choose Deep Threat Research from the list of analysis types.
5. Click the Enter icon to run the analysis.

That’s it. Within moments, your results appear — summary, investigation and mitigation guidance, ATT&CK mappings, detections, simulation, and all four visualizations, ready to explore, click into, and act on.

The Value You Gain

Deep Threat Research doesn’t just summarize a report — it operationalizes it. By pairing AI-driven analysis with the structure of MITRE ATT&CK and the SOC Prime Platform’s detection library, it turns every threat report your team encounters into a springboard for faster investigation, sharper mitigation, and stronger detection coverage. Less time reading. More time defending.

The post From Raw Threat Reports to Actionable Defense: AI-Powered Deep Threat Research appeared first on SOC Prime.

MikroTik has released emergency RouterOS security updates after researchers confirmed that attackers are actively exploiting a high-severity SSH authentication bypass against internet-facing routers. Tracked as CVE-2026-67276 and rated 9.2 on the CVSS scale, the flaw allows an attacker to authenticate as an existing RouterOS user without possessing that user’s legitimate RSA private key.

The vulnerability becomes significantly more dangerous when combined with CVE-2026-86060, a separate SSH privilege-escalation weakness. CERT Polska has named the two-stage attack chain MikroTrick and confirmed that attackers are using it to obtain full administrative control of RouterOS devices whose SSH service is reachable from public networks.

Evidence indicates that exploitation began as early as September 2, 2026, one day before MikroTik publicly released patched RouterOS builds on September 3. Successful attacks have created highly privileged accounts, modified device configuration, and established access that may survive until administrators actively investigate and rebuild compromised systems.

The broader group of MikroTrick Flaws disclosed by CERT Polska includes six RouterOS vulnerabilities affecting SSH server and client functionality, the bandwidth-test service, X.509 certificate validation, and the WebFig management interface. However, CVE-2026-67276 and CVE-2026-86060 form the combination currently confirmed in active full-device takeover attacks.

CVE-2026-67276 analysis

The vulnerability originates in the way RouterOS validates RSA public keys during SSH authentication. RouterOS did not compare the complete public key associated with an authorized user. Instead, only part of the RSA key was sufficiently validated, allowing a specially constructed alternative key to be accepted under conditions where it should have been rejected.

The most important details for CVE-2026-67276 are that an attacker needs to know a valid RouterOS username and the public modulus associated with that user’s authorized RSA SSH key. The attacker can then construct another key that passes the vulnerable validation process and authenticate without possessing the corresponding private key.

Successful exploitation of this flaw alone gives the attacker the same RouterOS permissions assigned to the impersonated account. If the targeted user already has administrative rights, that may directly provide significant control over the device. When the user’s permissions are more limited, attackers can combine the flaw with CVE-2026-86060 to escalate further.

CVE-2026-86060 stems from improper handling of specially crafted SSH usernames beginning with a prohibited character. The flaw allows manipulation of the RouterOS policy mask associated with the SSH session, enabling privilege escalation to full administrative rights. CERT Polska confirms that exploiting the two weaknesses together enables unauthenticated takeover of a RouterOS device when SSH is exposed.

This chain is especially important because it removes the usual requirement to steal a valid administrator password or private SSH key. An external actor capable of reaching the SSH service may be able to move from crafted authentication attempts to a privileged RouterOS session and then perform administrative operations.

Attempts to exploit MikroTik RouterOS in observed attacks have focused on devices exposing SSH directly to the internet. MikroTik notes that default home configurations are generally not immediately exposed, but administrators who have enabled public SSH or changed firewall rules may face substantially greater risk.

CVE-2026-67276 affects the following RouterOS release ranges:

• RouterOS 7.24 through versions before 7.24.2
• RouterOS 7.0.0 through versions before 7.23.4
• RouterOS 6.0.0 through versions before 6.49.21

CERT Polska categorized the vulnerability as CWE-347: Improper Verification of Cryptographic Signature. All six RouterOS security issues disclosed in the same research share the same broad affected release ranges.

The vulnerability was discovered by CERT Polska as part of security research performed in coordination with MikroTik. Researchers used an agent-based laboratory environment supported by AI models to analyze RouterOS components, compare software versions, model protocol states, and validate hypotheses against real test systems. Each finding was subsequently confirmed manually and through repeat testing before disclosure.

The precise private discovery date has not been published. MikroTik released the security fixes on September 3, 2026, while CERT Polska published technical information and the assigned CVEs on September 5. Real-world evidence indicates that attackers were already exploiting the chain by September 2, giving the campaign zero-day characteristics.

Researchers have confirmed successful attacks originating from 82.192.72[.]4, with exploitation attempts also associated with 103.102.31[.]18. Observed compromises created a highly privileged RouterOS user named ops.

Security Affairs also reported infrastructure at 82.192.72[.]4 hosting a MIPS BusyBox binary and files named ftpsrv.py, launch.sh, and serve.py. The available evidence has not yet tied the activity to a named threat group or established whether the compromised routers are being assembled into a botnet, proxy network, espionage infrastructure, or another operation.

The observed attack chain leaves particularly useful artifacts in RouterOS logs and configuration history. Failed exploitation attempts can generate entries resembling:

login failure for user -2 from <ip> via ssh

Successful activity may subsequently appear as:

user <name> added by ssh:-2@<ip>

The string -2 is especially suspicious because it is not a normal RouterOS username and has been associated with exploitation of the privilege-manipulation stage.

A public CVE-2026-67276 PoC has now appeared for controlled laboratory testing of the SSH authentication weakness. Its availability further lowers the barrier for independent reproduction of the flaw, reinforcing the need to patch before scanning and exploitation become more widespread.

Useful CVE-2026-67276 IOCs currently include the two observed source IP addresses, the abnormal -2 SSH username, the ops account, and configuration changes attributed to ssh:-2@<IP>. Security Affairs additionally published hashes for several files recovered from associated attacker infrastructure.

CVE-2026-67276 Mitigation

MikroTik and CERT Polska recommend upgrading RouterOS immediately. Fixes are available in:

• RouterOS 7.25 beta 3 or later
• RouterOS 7.24.2 or later
• RouterOS 7.23.4 or later
• RouterOS 6.49.21 or later

MikroTik subsequently released RouterOS 7.23.5 after an IPv6 DHCP regression was discovered in 7.23.4. Organizations using the long-term 7.23 branch should therefore use the latest available maintenance build rather than intentionally stopping at 7.23.4.

After updating, RouterOS performs a startup check for selected known indicators of unauthorized configuration changes. If suspicious modifications are identified, the device is assigned a Flagged status, the relevant configuration entries can be disabled, and a critical warning is written to the system log.

Administrators can inspect this state with:

/system/device-mode/print

A Flagged result should be treated as evidence that the device may have been compromised. However, both MikroTik and CERT Polska emphasize that the absence of the Flagged marker does not prove that a router is clean, because the mechanism only detects selected known artifacts.

CVE-2026-67276 detection should therefore combine patch verification with log review, configuration inspection, and analysis of recently created accounts and administrative changes.

To Detect CVE-2026-67276 exploitation or related MikroTrick activity, defenders should look for:

• login failure for user -2 … via ssh
• Administrative actions attributed to ssh:-2@<IP>
• An unexpected privileged account named ops
• Connections involving 82.192.72[.]4
• Connections involving 103.102.31[.]18
• Newly added or modified SSH public keys
• Unknown users or changed user permissions
• Unexpected RouterOS scripts
• Suspicious scheduler tasks
• Newly enabled proxies or tunnels
• Unexplained firewall or NAT modifications
• Packet-sniffing or traffic-forwarding configuration that administrators did not create
• Other unexpected configuration changes following SSH activity

If administrators cannot patch immediately, CERT Polska recommends disabling externally exposed services or restricting them exclusively to trusted management networks. This applies particularly to SSH, WWW/WWW-SSL, and the bandwidth-test server.

Unpatched devices should also avoid initiating SSH or TLS connections toward untrusted systems. CERT Polska specifically recommends avoiding RouterOS’s built-in /system ssh and /system ssh-exec clients until updates are installed because other vulnerabilities disclosed in the same research affect RouterOS client-side trust and protocol handling.

These measures reduce exposure but do not replace the vendor update.

If logs, the Flagged status, an unknown ops account, or other configuration evidence suggests compromise, administrators should treat the router as fully controlled by an attacker. The affected device should be isolated, and relevant logs and configuration evidence should be preserved before remediation.

CERT Polska then recommends restoring the device to factory settings and rebuilding the configuration from a trusted and verified source. Administrators should not simply restore a complete backup created from a potentially compromised router because malicious users, scripts, SSH keys, scheduler entries, proxies, or tunnels could be reintroduced.

All passwords, SSH keys, API credentials, VPN secrets, and other authentication material exposed to or stored on a compromised device should also be rotated.

The CVE-2026-67276 mitigation priority is particularly high for routers that exposed SSH to the public internet before September 3. Because active attacks began before the security update became publicly available, patching those systems should be accompanied by retrospective investigation rather than treated solely as preventive maintenance.

The post CVE-2026-67276: MikroTik RouterOS SSH Zero-Day Exploited in Router Takeover Attacks appeared first on SOC Prime.

Cisco has released security updates for a critical vulnerability affecting selected Nexus 9000 Series switches that can allow an unauthenticated remote attacker to execute arbitrary code with root privileges. Tracked as CVE-2026-20212 and rated 9.8 on the CVSS scale, the flaw affects Nexus 9000 models equipped with a Cisco Silicon One ASIC.

The vulnerability stems from an unintended network exposure in the Silicon One integration. TCP ports 43210 and 43211 are accessible through the default Layer 3 virtual routing and forwarding (VRF) instance, allowing an attacker who can reach either port to connect directly to the vulnerable service. Crafted input sent through the exposed service can then be executed with root privileges.

Successful exploitation can also crash the S1HAL process, potentially forcing the affected switch to reload and causing network disruption. Cisco said its Product Security Incident Response Team was not aware of malicious exploitation or public announcements targeting the flaw when the advisory was released on September 2, 2026.

The vulnerability is especially significant because Nexus 9000 switches commonly operate at the center of enterprise and data-center networks. Root-level compromise could give an attacker extensive control over network configuration and potentially create opportunities for traffic interception, service disruption, persistence, or movement toward connected infrastructure.

Contact Sales

CVE-2026-20212 analysis

The vulnerability is classified as CWE-1327: Binding to an Unrestricted IP Address. The underlying problem is not an authentication implementation error but the exposure of a privileged Silicon One service through interfaces where it should not be reachable.

Under the default Layer 3 VRF configuration, TCP ports 43210 and 43211 listen in a manner that allows remote systems to reach the service. An attacker does not need a valid Cisco account, administrator credentials, or an existing foothold on the switch. They only need network connectivity to one of the affected device’s locally configured addresses on either vulnerable port.

Once connected, an adversary can send specially crafted input to the exposed service. Cisco confirms that this input can be interpreted and executed as code with root privileges, effectively giving the attacker the highest level of operating-system control available on the device.

The most important details for CVE-2026-20212 are reflected in its CVSS vector: network-based exploitation, low attack complexity, no privileges required, and no user interaction. Successful exploitation can have high impact on confidentiality, integrity, and availability.

CVE-2026-20212 affects Nexus 9000 switches containing a Silicon One ASIC. Cisco lists the following product identifiers as vulnerable at the time of disclosure:

• N9324C-SE1U
• N9348Y2C6D-SE1U
• N9364E-SG2-O
• N9364E-SG2-Q
• N9396T12C-SE1
• N9348Y12C-SE1
• N9396Y12C-SE1
• N9336C-SE1
• N9K-C9804
• N9K-C9808

To determine the PID for a device, use the show module CLI command. In the following example, the PID of the device is N9336C-SE1, which is on the list of devices that are affected by this vulnerability.

Cisco’s CVE record lists 45 affected NX-OS releases, beginning with 10.3(1) and extending through releases including 10.6(3) and 10.6(3s). Because exposure depends on both the switch model and NX-OS version, organizations should verify each system through Cisco’s Software Checker rather than relying only on the broad version range.

Cisco has confirmed that Nexus 9000 models not listed in the advisory are not affected. Nexus 9000 Fabric Switches operating in Application Centric Infrastructure (ACI) mode are also not vulnerable.

Other confirmed unaffected products include:

• Nexus 3000 Series switches
• Nexus 7000 Series switches
• MDS 9000 Series multilayer switches
• Cisco Firepower appliances
• Secure Firewall products
• Multiple UCS Fabric Interconnect platforms

This distinction is important because the vulnerability is specifically tied to the Silicon One integration present in the affected Nexus 9000 hardware rather than to NX-OS universally.

The potential post-compromise impact is substantial. An attacker operating as root could theoretically modify switch configuration, interfere with network services, manipulate routing or forwarding behavior, monitor traffic available to the compromised device, or attempt to establish persistence. These are realistic consequences of root-level device compromise, although Cisco has not reported such activity occurring through this vulnerability.

Exploitation can also have an immediate availability impact without establishing long-term access. Cisco warns that attempts to exploit the flaw can cause the Silicon One Hardware Abstraction Layer process, S1HAL, to crash. A crash can cause the entire device to reload, potentially interrupting connectivity for systems depending on the affected switch.

Cisco discovered the vulnerability while resolving a Technical Assistance Center support case. The company has not disclosed the exact date on which the underlying security issue was first identified. The public security advisory was issued on September 2, 2026.

As of September 4, Cisco said it was not aware of malicious exploitation, and CISA’s vulnerability enrichment data classified exploitation as none while describing the issue as automatable with total technical impact.

There was also no confirmed public CVE-2026-20212 PoC identified in Cisco’s disclosure or the two requested reports. The absence of public exploit code should not significantly reduce remediation priority, however, because the basic network exposure and vulnerable ports are already publicly documented.

Cisco has not published campaign-specific CVE-2026-20212 IOCs, which is expected because no attacks have been confirmed. Defenders should instead focus on attempts to access TCP 43210 or 43211, Live Protect events, unexpected S1HAL instability, and unauthorized changes occurring on affected devices.

CVE-2026-20212 Mitigation

Cisco has released fixed NX-OS software and strongly recommends upgrading affected Nexus switches. Rather than publishing a single fixed-version table in the advisory, Cisco directs customers to its Software Checker, which identifies whether a specific NX-OS version is affected and returns the earliest fixed release for that platform.

Administrators should therefore:

1. Run show module to identify the switch model.
2. Confirm whether its PID appears in Cisco’s vulnerable-product list.
3. Determine the installed NX-OS release.
4. Use Cisco Software Checker to identify the appropriate fixed release.
5. Upgrade affected systems as soon as operationally possible.

For organizations that cannot immediately upgrade, Cisco provides an infrastructure access control list workaround. Administrators can configure iACLs to allow only required management and control-plane traffic or explicitly deny TCP traffic destined for a locally configured switch address on ports 43210 and 43211.

Cisco states that the workaround was successfully validated in a test environment, but organizations should evaluate its effect on their individual network design before deployment. Network-level mitigations can affect expected functionality when applied without considering local architecture.

Cisco has additionally released Live Protect shield lp00031 as a temporary mitigation. The shield blocks attempts to exploit CVE-2026-20212 while administrators prepare a full software upgrade. Cisco emphasizes that Live Protect is a bridge to patching rather than a permanent remediation.

The Live Protect documentation provides a useful security signal as well. Administrators can verify that the shield is in enforcement mode with:

show nxsecure policy status

They can inspect recorded events using:

show nxsecure log lp00031

When the shield blocks activity targeting the vulnerability, NX-OS can generate a critical NXSECURE syslog indicating a hit against CVE-2026-20212.

For affected systems running NX-OS 10.6(3), Cisco documents support for shield lp00031. A separate package is available for the N9324C-SE1U and N9348Y2C6D-SE1U Smart Switches running 10.6(3s). Cisco’s shield documentation states that the mitigation transitions to N/A when upgrading to NX-OS 10.6(4) or higher, but customers should still use Software Checker to confirm the correct fixed release for their specific hardware and software combination.

CVE-2026-20212 detection should start with identifying affected hardware and monitoring access to the two exposed service ports. Network telemetry, ACL logs, NetFlow data, switch logs, and intrusion detection systems can help identify suspicious attempts to reach TCP 43210 or 43211.

To Detect CVE-2026-20212 exploitation attempts or related compromise, defenders should investigate:

• Unexpected inbound connections to TCP ports 43210 or 43211
• Live Protect lp00031 hit events
• %APPMGR-2-NXSECURE_CRIT_THREAT messages associated with the vulnerability
• Unexpected crashes or restarts of the S1HAL process
• Unplanned Nexus switch reloads
• Administrative or configuration changes without a corresponding authorized activity
• New or unusual processes running on the switch
• Unexpected outbound connections originating from the network device
• Changes to access-control, routing, forwarding, or management configuration
• Attempts to disable logging or security controls following suspicious network traffic

Cisco has also published Snort Rule 67005 in connection with the advisory, providing another detection option for organizations using compatible Cisco security tooling.

If suspicious activity is identified on an unpatched switch, defenders should treat the event as potentially serious because exploitation provides root privileges. Incident response should include configuration validation, administrative account review, log preservation, comparison against known-good device state, and investigation of systems communicating with the affected switch.

The CVE-2026-20212 mitigation priority should be particularly high for devices whose affected ports are reachable from user segments, externally accessible networks, or other untrusted infrastructure. Blocking the ports can substantially reduce immediate exposure, but upgrading to Cisco’s fixed software remains the vendor-recommended permanent solution.

The post CVE-2026-20212: Critical Cisco Nexus 9000 Flaw Enables Unauthenticated Root RCE appeared first on SOC Prime.

Google has released an emergency Chrome security update addressing a high-severity zero-day vulnerability that is already being exploited in the wild. Tracked as CVE-2026-85046 and rated 8.8 on the CVSS scale, the flaw is a type confusion issue in V8, the JavaScript and WebAssembly engine used by Google Chrome.

Successful exploitation can allow a remote attacker to execute arbitrary code inside Chrome’s sandbox after a victim visits a specially crafted HTML page. Google has confirmed that an exploit exists in the wild but has not disclosed information about the threat actors, targeted organizations, or attack campaigns while the update is still rolling out.

CVE-2026-85046 affects Chrome versions earlier than 152.0.7977.82. Google has released Chrome 152.0.7977.82/.83 for Windows and macOS and 152.0.7977.82 for Linux, with the security update being distributed progressively to users.

The vulnerability is the sixth Chrome zero-day Google has addressed in 2026 after previously exploited flaws including CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, and CVE-2026-11645.

CVE-2026-85046 analysis

The vulnerability is categorized as CWE-843: Access of Resource Using Incompatible Type, commonly referred to as type confusion. This class of memory-safety weakness occurs when software incorrectly treats an object as a different data type than the one actually stored in memory.

In JavaScript engines such as V8, incorrect assumptions about object types can become particularly dangerous because highly optimized compiler paths depend on accurate information about how arrays and objects are represented in memory.

Security researcher Salvatore Gulizia, also known as Serotav, explained that the flaw involves V8 compiler behavior where an array containing PACKED_ELEMENTS can incorrectly receive a PACKED_SMI_ELEMENTS map. That mismatch can ultimately be transformed into arbitrary read and write access within the JavaScript heap.

The most important details for CVE-2026-85046 are that exploitation is remotely reachable, requires no existing privileges, and can be delivered through malicious web content. The published CVSS vector indicates that user interaction is required, meaning the victim must load attacker-controlled content, such as by visiting a malicious or compromised page.

A typical exploitation scenario could begin when a user follows a phishing link, encounters a malicious advertisement, or visits a legitimate website that has been compromised. Crafted JavaScript or HTML content could then trigger the V8 type confusion and corrupt the assumptions Chrome uses when accessing objects in memory.

The resulting primitive can enable arbitrary code execution inside the Chrome sandbox. This distinction is important: CVE-2026-85046 alone does not necessarily provide complete control over the underlying operating system. A threat actor seeking full host compromise would normally need to combine browser code execution with an additional sandbox escape or privilege-escalation vulnerability.

Google has deliberately restricted access to the Chromium bug report while most users receive the patch. This is standard practice for actively exploited Chrome vulnerabilities because publishing complete technical details too quickly could make it easier for additional attackers to reverse-engineer and weaponize the flaw.

The vulnerability was reported to Google by Salvatore Gulizia on August 4, 2026. Google awarded the researcher a $1,000 bug bounty, and the flaw was publicly patched as part of the September 3 Stable Channel update.

The update fixes 12 security vulnerabilities in total. Besides the exploited V8 issue, Google addressed high-severity weaknesses involving CrashReporting, Network, Compositing, another V8 race condition, WebGL, CacheStorage, DevTools, and Skia, as well as two medium-severity issues.

Google has confirmed active exploitation but has not released a public CVE-2026-85046 PoC. Access to the underlying Chromium issue also remains restricted, limiting the technical information currently available for reproducing the exploit.

There are likewise no campaign-specific CVE-2026-85046 IOCs published by Google. The company has not identified malicious domains, IP addresses, payload hashes, or specific exploitation infrastructure associated with the observed attacks.

The absence of public indicators makes vulnerability exposure and behavioral telemetry more important than static threat intelligence. Organizations should assume that any endpoint running an affected browser version can remain exposed when users browse attacker-controlled content.

Contact Sales

CVE-2026-85046 Mitigation

Google recommends upgrading Chrome immediately to:

• 152.0.7977.82/.83 or later on Windows
• 152.0.7977.82/.83 or later on macOS
• 152.0.7977.82 or later on Linux

Users can verify the installed version by opening Chrome → Help → About Google Chrome. The browser will check for updates automatically, but Chrome must be relaunched after installation for the new version and security fixes to become active.

Enterprise administrators should verify deployment rather than relying exclusively on Chrome’s gradual automatic rollout. Managed endpoints that have not restarted after receiving the update may continue running the vulnerable browser process until users relaunch Chrome.

CVE-2026-85046 detection should begin with endpoint inventory. Security teams should identify systems running Chrome releases earlier than 152.0.7977.82 and prioritize endpoints exposed to external browsing, email links, web advertising, and other untrusted web content.

To Detect CVE-2026-85046 exploitation or suspicious browser activity, defenders should look for combinations of:

• Chrome renderer crashes followed by unusual process activity
• Unexpected processes launched from the Chrome process tree
• Browser exploitation alerts generated by EDR or endpoint protection tools
• Suspicious memory-corruption behavior involving Chrome or V8
• Visits to newly registered, compromised, or known malicious websites immediately before anomalous activity
• Unexpected executable or script activity following a browser session
• Attempts to exploit a second vulnerability after Chrome renderer compromise
• New persistence or privilege-escalation activity occurring immediately after suspicious browser behavior

These signals are hunting leads rather than exploit-specific signatures because Google has not disclosed the in-the-wild exploitation technique.

Organizations should also review web proxy, DNS, EDR, and email-security telemetry around suspicious Chrome events. Since exploitation requires loading crafted web content, correlating browser crashes or unusual child-process activity with recently visited domains can help identify possible attack chains.

Chromium-based browsers such as Microsoft Edge, Brave, Opera, and Vivaldi also rely on Chromium components, including V8. Users of these products should install vendor updates containing the corresponding Chromium security fix as soon as those releases become available.

Because exploitation was already underway before public disclosure, CVE-2026-85046 mitigation should include both rapid patching and retrospective investigation of suspicious browser activity on systems that remained vulnerable before September 3.

The post CVE-2026-85046: Actively Exploited Chrome V8 Zero-Day Enables Code Execution appeared first on SOC Prime.

Today, Recorded Future is announcing Automated Signature Creation, a new capability in Attack Surface Intelligence (ASI) to combat the speed of AI-generated exploits.

ASI continuously maps an organization’s external exposure, correlates newly surfaced vulnerabilities with real-world threat intelligence, and prioritizes response to enable defenders to remediate before adversaries can act.

This new function within ASI automatically creates signatures, pieces of detection logic that empowers the Recorded Future Platform to recognize a specific vulnerable or exposed condition across organization’s assets in real time.

With Automated Signature Creation now available, Recorded Future is helping to close the gap between AI-enabled threat discovery and enterprise defense.

Tackling the machine speed of exploitable vulnerabilities

It seems everything is moving quicker these days and the time to exploit a vulnerability is no different. A new generation of AI models is accelerating this challenge, demonstrating that they can automatically find zero-day vulnerabilities in major operating systems and web browsers — a skill that was previously exclusive to the most advanced government cyber units and research labs.

Back in 2020, we cited how Gartner confirmed that the time from discovery to exploitation dropped from 45 days to 15 days, between 2010 to 2020.

In our 2025 Malware and Vulnerability Trends report, we reported that weaponization occurred “within days of disclosure." Today, that window is measured in hours.

As a result, the status quo of traditional defenses and manual processes are no longer sufficient. Let’s look back at how we got here, from pre-existing detection methods to Recorded Future’s latest ASI enhancement to better defend against AI-accelerated vulnerabilities.

How we got here

In the past year, Recorded Future’s traditional approach of expert-authored signatures from the Insikt Group® was effective; they were high quality but moved at a human pace.

For example, in February 2025 we reported on the Trimble Cityworks: CVE-2025-0994, showcasing how manual signature creation worked. The Insikt Group built a Nuclei template (shared as a downloadable YAML file) specifically for CVE-2025-0994. This enabled defenders to test potentially vulnerable Trimble Cityworks instances prior to the patched version, serving as a detection and prioritization aid for helping teams figure out where to focus patching efforts first. This worked in conjunction with one of ASI’s core functions, scanning web infrastructure to identify internet-facing assets vulnerable to CVE-2025-0994.

Since that vulnerability disclosure a little over a year ago, we have ample evidence that the speed at which vulnerabilities are exploited has increased exponentially. Just recently, it was reported that OpenAI’s own agents went rogue and exploited a zero-day vulnerability in Artifactory, now infamously tied to the Hugging Face incident.

Incidents like this one, and the underlying vulnerabilities that facilitate them, are exactly why Recorded Future automated signature creation.

Now, in the face of an attack moving at machine speed, agentic processing generates production-ready detection signatures autonomously by turning a newly surfaced vulnerability into a deployable signature in as little as 31 minutes. As a result, the number of in-platform signatures produced has increased tenfold. Let’s take a closer look at how it works.

How automated signature creation works

So what does a signature in this context actually mean? Think of it like this: the signature is a piece of detection logic that says "go ask this asset this exact question; if the answer looks like this, it's vulnerable." It's the difference between "we found your assets" and "we found the ones a threat actor can potentially break into."

Automated signature creation works like a three-step early warning system. (See Figure 1)

1. The platform keeps a constant view of what your organization exposes to the internet such as domain records, certificates, and ownership data.
2. When a new vulnerability is flagged and matched against your scanned assets, it's checked against live threat activity rather than just a generic severity score. The system looks for evidence that threat actors are actually exploiting it, tying it to malware, ransomware or threat actor intent.
3. When Recorded Future Intelligence determines a CVE is relevant for detection, the system automatically processes it to generate a detection signature or product fingerprint in as little as 31 minutes.

Figure 1: CVE disclosures mapped to external assets kick off automated processes

SonicWall has released emergency security updates for two vulnerabilities affecting its Secure Mobile Access (SMA) 1000 series appliances after confirming that both flaws have been exploited in the wild. Tracked as CVE-2026-83548 and CVE-2026-83549, the issues affect the Appliance Work Place and Appliance Management Console components and may be chained to move from unauthenticated external access to arbitrary operating-system command execution.

The more severe vulnerability, CVE-2026-83548, carries a maximum CVSS score of 10.0. It is a pre-authentication server-side request forgery (SSRF) flaw caused by an unintended alternate access path in the Appliance Work Place interface. A remote attacker can exploit it without credentials to reach sensitive functionality and perform unauthorized operations.

CVE-2026-83549 is rated 7.8 and affects the Appliance Management Console. Under specific conditions, an authenticated administrator can exploit an OS command injection weakness to execute arbitrary commands, potentially resulting in remote code execution on the appliance.

The combination is what makes these SonicWall product vulnerabilities particularly dangerous. SonicWall says it investigated a case showing active exploitation of both issues, while SecurityWeek and The Hacker News note that the activity suggests attackers may be chaining the pre-authentication weakness with the command injection flaw to execute code on vulnerable SMA 1000 devices.

CVE-2026-83548 and CVE-2026-83549 analysis

CVE-2026-83548 resides in the SMA 1000 Appliance Work Place interface and is categorized as a pre-authentication SSRF vulnerability. The weakness exists because an unintended alternate access path allows requests to reach functionality that should not be accessible to an unauthenticated remote user.

The most important details for CVE-2026-83548 are reflected in its attack requirements. The vulnerability is reachable over the network, requires low attack complexity, does not require prior privileges, and does not need user interaction. Its CVSS vector indicates potentially high confidentiality, integrity, and availability impact if the vulnerable path is successfully abused.

Unlike a conventional SSRF bug that may simply force a server to make an outbound request, SonicWall describes this issue as enabling unauthorized access to sensitive functionality and unauthorized operations. That broader impact explains the maximum 10.0 severity rating and why the flaw is especially concerning on internet-facing remote-access appliances.

CVE-2026-83549 operates later in a potential attack chain. It is an OS command injection vulnerability in the Appliance Management Console. SonicWall says a remote authenticated attacker operating as an administrator can exploit the weakness under specific conditions to execute arbitrary OS commands, resulting in remote code execution.

CVE-2026-83549 affects the same SMA 1000 firmware branches as the SSRF issue. The potentially important relationship between the two flaws is that the first weakness removes the normal authentication barrier to sensitive functionality, while the second requires administrative access before command execution becomes possible.

SonicWall has not publicly documented the exact technical steps connecting the two vulnerabilities. However, because the vendor confirmed exploitation of both issues in the same investigated case, SecurityWeek and The Hacker News assess that threat actors may be combining them to achieve unauthenticated remote code execution.

This distinction matters. CVE-2026-83549 alone should not be described as a pre-authentication RCE vulnerability. Its documented prerequisite is on its own, exploitation requires an authenticated administrator and specific system conditions. The concern is that CVE-2026-83548 may provide the unauthorized access required to reach or enable the command-injection path.

The affected hardware and virtual platforms are:

• SMA 6210
• SMA 7210
• SMA 8200v, across all supported hypervisors

SonicWall lists the vulnerable firmware ranges as 12.4.3-03453 and earlier and 12.5.0-02835 and earlier.

The flaws do not affect SSL VPN functionality on SonicWall firewalls or the separate SMA 100 series. They are specific to the SMA 1000 product family covered by SonicWall advisory SNWLID-2026-0016.

The vulnerabilities are notable partly because SMA appliances are commonly placed at the enterprise perimeter and provide remote access to internal resources. Successful compromise of such a system can potentially give attackers a valuable foothold close to authentication infrastructure, internal applications, and privileged network paths.

Contact Sales

If attackers gain arbitrary command execution on the appliance, potential consequences include persistence, credential theft, configuration manipulation, traffic interception, additional malware deployment, and lateral movement toward internal systems. The public reporting does not confirm that all of these activities occurred in the current exploitation, but they represent realistic post-compromise risks once an adversary gains OS-level command execution on a remote-access gateway.

Both vulnerabilities were discovered internally by SonicWall. The Hacker News credits William Perry and Adam Babis with identifying the issues. The CVE records and vendor advisory were published on September 1, 2026, but SonicWall has not disclosed the original internal discovery date or how long the threat actors may have been exploiting the new flaws before remediation became available.

The disclosure follows a separate series of SMA 1000 zero-days patched in July 2026, CVE-2026-15409 and CVE-2026-15410. Those earlier vulnerabilities were exploited by a threat actor tracked as UTA0533 and were associated with KNUCKLEBALL malware. SonicWall explicitly states that CVE-2026-83548 and CVE-2026-83549 are unrelated to previously reported vulnerabilities in other SonicWall products.

As of the initial September disclosure, there was no indexed public CVE-2026-83548 PoC identified by the sources reviewed. Despite the absence of public exploit code, confirmed in-the-wild exploitation means defenders should assume working private exploit capability already exists.

SonicWall has also not disclosed who is behind the new attacks, which organizations were targeted, or whether the activity is linked to espionage, cybercrime, ransomware, or the actors responsible for the earlier SMA 1000 campaign.

No complete public set of CVE-2026-83549 IOCs accompanied SonicWall’s initial notice. The vendor instead instructs affected customers to contact SonicWall Technical Support for assistance reviewing appliances for evidence of compromise.

That absence of campaign-specific indicators makes configuration and behavioral monitoring particularly important. Organizations should not wait for a malicious IP address, payload hash, or exploit signature before investigating an internet-facing appliance that remained vulnerable during the exploitation window.

CVE-2026-83548 and CVE-2026-83549 Mitigation

SonicWall recommends that every organization operating affected physical or virtual SMA 1000 appliances immediately upgrade to the latest hotfix. The fixed firmware versions are:

• 12.4.3-03526
• 12.5.0-02952

Any later release containing these security fixes should also address the vulnerabilities. Organizations should verify the installed platform-hotfix version rather than assuming a system is protected simply because it runs the 12.4.3 or 12.5.0 branch.

CVE-2026-83548 detection should begin with a full inventory of SMA 1000 appliances and verification of their exact firmware builds. Systems running 12.4.3-03453 or older, or 12.5.0-02835 or older, should be considered exposed and prioritized for investigation as well as patching.

To Detect CVE-2026-83549 exploitation or suspicious activity related to the potential chain, security teams should review appliance, management, authentication, and network telemetry for signs such as:

• Unexplained administrative sessions
• Privileged actions without corresponding legitimate administrator activity
• Unexpected commands or processes executed by appliance services
• Configuration changes originating from unfamiliar sources
• Suspicious requests to the Appliance Work Place interface
• Activity reaching management functionality without a normal authentication sequence
• New or modified administrator accounts
• Unexpected outbound connections from the SMA appliance
• Changes to authentication or remote-access configuration
• Attempts to disable logging, monitoring, or security controls
• Suspicious activity immediately preceding OS command execution

These behaviors are investigation leads rather than vulnerability-specific signatures because SonicWall has not publicly documented the complete exploit chain.

Organizations should also preserve appliance logs before upgrading where practical. Installing fixed firmware prevents future exploitation through the known flaws, but it does not identify or remove persistence established before remediation.

The CVE-2026-83549 mitigation guidance is particularly important for appliances showing any suspicious indicators. SonicWall instructs customers to contact Technical Support for help reviewing the system and, when compromise indicators are detected, take the following steps:

• Upgrade to the latest hotfix version – available via https://www.mysonicwall.com
• Contact SonicWall Technical Support for assistance reviewing the system for indicators of compromise (IoCs).
• If IOCs are detected on the system:
• Re-image (hardware) or re-deploy (virtual) appliances.
• Change all user & administrator passwords.
• Reset TOTP tokens

Credential rotation is necessary because an attacker with administrative or OS-level access may have been able to obtain authentication data or establish access that remains useful after the vulnerable firmware itself has been replaced.

Organizations should also review systems reachable through the affected remote-access gateway. A compromised SMA appliance should not be treated as an isolated perimeter event if logs indicate successful arbitrary command execution. Incident response should examine downstream authentication systems, administrative interfaces, internal servers, and credentials potentially accessible from the appliance.

Reducing external exposure provides another layer of protection. Management functions should only be reachable from authorized administrative networks or controlled access paths. Organizations should restrict unnecessary internet access, enforce network segmentation, and monitor administrative interfaces for unexpected connections.

SonicWall’s response guidance is particularly important because these vulnerabilities are already being exploited. Patching should therefore be combined with retrospective threat hunting rather than treated as a purely preventive maintenance task.

The post CVE-2026-83548 and CVE-2026-83549: SonicWall SMA 1000 Zero-Days Exploited in the Wild appeared first on SOC Prime.

A critical authentication bypass vulnerability in JFrog Artifactory moved into active exploitation only days after its public disclosure. Tracked as CVE-2026-82329 and rated 9.8 on the CVSS scale, the flaw can allow an unauthenticated attacker with network access to obtain administrator-level privileges on vulnerable Artifactory instances.

JFrog disclosed and patched the issue on August 28, 2026. By September 1, exposure management company watchTowr had already observed attackers exploiting vulnerable systems to generate administrative tokens and enumerate users, groups, credentials, and federated access relationships.

The Critical JFrog Artifactory Vulnerability is particularly dangerous because Artifactory frequently occupies a privileged position in software development and delivery pipelines. Organizations use it to store and distribute binaries, containers, packages, AI models, and other software artifacts. Administrative compromise can therefore create opportunities not only for data theft but also for software supply-chain manipulation and lateral movement into production infrastructure.

JFrog Cloud environments have already been secured by the vendor. Organizations operating self-hosted Artifactory deployments must upgrade to the fixed release corresponding to their current branch.

CVE-2026-82329 analysis

The vulnerability is categorized as CWE-287: Improper Authentication. JFrog’s advisory states that “JFrog Artifactory contains an authentication weakness” that, under the default configuration, can allow a remote attacker without credentials to gain administrative privileges.

The flaw resides in JFrog Access, the platform component responsible for issuing and validating credentials. According to watchTowr’s analysis cited by The Hacker News, vulnerable installations without an additional join key configured can receive what researchers describe as a “phantom” join key. An attacker can abuse this condition to forge access and generate administrator-level token.

This is what makes the vulnerability significantly more severe than a conventional information-disclosure bug. The attacker does not need to steal a legitimate username, password, API key, or session first. The CVSS vector confirms network-based exploitation with low complexity, no privileges required, and no user interaction. Confidentiality, integrity, and availability are all rated as having high potential impact.

The most important details for CVE-2026-82329 concern what attackers can do after the authentication boundary is bypassed. WatchTowr observed threat actors minting administrator tokens, then using those privileges to inspect the environment and determine whether it was valuable enough for deeper exploitation.

Observed post-exploitation activity included enumeration of:

• Existing Artifactory users
• User groups
• Authentication tokens and credential sets
• Federated access relationships
• Other information useful for understanding how the Artifactory environment connects to surrounding infrastructure

In a limited number of attacks, threat actors went further and created backdoor users, establishing an additional path for persistent administrative access.

The exploited critical JFrog Artifactory flaw poses a broader security concern because Artifactory is often part of CI/CD and software distribution workflows. Administrator-level access may allow an adversary to inspect repositories, alter configuration, access stored credentials, or potentially interfere with artifacts that are later consumed by build and deployment systems.

WatchTowr warned that compromise of a central software supply-chain platform could allow attackers to tamper with build pipelines, move laterally toward production infrastructure, or introduce malicious changes that could ultimately propagate downstream. The available reporting does not confirm that these more severe supply-chain scenarios have occurred in the observed attacks, but administrator compromise makes them realistic post-exploitation risks.

CVE-2026-82329 affects multiple supported Artifactory 7.x branches. JFrog lists the vulnerable and fixed versions as follows:

• 7.161.x: upgrade to 7.161.20
• 7.146.x: upgrade to 7.146.38
• 7.133.x: upgrade to 7.133.29
• 7.125.x: upgrade to 7.125.20
• 7.117.x: upgrade to 7.117.28
• 7.111.x: upgrade to 7.111.21

JFrog published the vulnerability on August 28, 2026. The exact original discovery date and circumstances have not been publicly disclosed in the vendor advisory. The speed with which exploitation followed disclosure is notable: watchTowr began observing real-world activity on September 1, only four days after the advisory and fixes became public.

WatchTowr’s global honeypot network initially saw exploitation originating from a relatively small number of IP addresses across different geographic regions. Researchers said the activity had not yet developed into broad mass scanning at the time of their report.

Some attempts appeared to stop after simply verifying that exploitation worked. Others proceeded to enumerate the compromised instance, suggesting attackers were assessing exposed environments before deciding whether to continue with deeper intrusion activity.

Public technical reproduction information has also started to emerge. A CVE-2026-82329 PoC published after disclosure demonstrates an unauthenticated path to administrator-level token generation against a vulnerable Artifactory build and shows the same attempt being rejected by a patched release. This further increases the urgency of updating exposed systems because exploitation no longer requires independently reverse-engineering the vulnerability from scratch.

At the time of reporting, the activity had not been attributed to a specific ransomware operation, state-sponsored group, or other established threat actor. There was also no evidence that exploitation had reached widespread automated scanning levels.

There is currently no comprehensive vendor-published set of CVE-2026-82329 IOCs that can reliably identify every exploitation attempt. The observed attacks instead provide behavioral indicators: unexpected administrative tokens, unauthorized users, unusual account enumeration, and access to federated authentication information should all be treated as potential signs of compromise.

Contact Sales

CVE-2026-82329 Mitigation

JFrog recommends that organizations running self-hosted Artifactory installations immediately upgrade to the fixed version applicable to their release branch. The vendor confirms that affected cloud environments have already been fortified and require no customer action for this specific issue.

Self-hosted customers should update to one of the following versions or a newer supported release containing the fix:

• 7.161.20
• 7.146.38
• 7.133.29
• 7.125.20
• 7.117.28
• 7.111.21

Because active exploitation began within days of disclosure, internet-facing instances should receive the highest patching priority. Organizations should not rely solely on the absence of obvious malicious activity, particularly because some observed attackers appeared to validate the vulnerability and stop, potentially leaving few immediately visible post-exploitation artifacts.

CVE-2026-82329 detection should begin with identifying all self-managed Artifactory instances and comparing their exact versions against JFrog’s vulnerable ranges. Security teams should then determine which systems are exposed to untrusted networks and prioritize those instances for both patching and retrospective investigation.

To Detect CVE-2026-82329 exploitation or post-compromise activity, defenders should review Artifactory and JFrog Access audit data for:

• Unexpected administrator-level tokens
• Tokens created without a corresponding legitimate administrator action
• Newly created or any other accounts
• Unusual enumeration of users and groups
• Requests that enumerate token or credential information
• Sudden administrative activity originating from unfamiliar IP addresses
• Repository or permission changes following suspicious authentication activity
• New access relationships between Artifactory and connected development infrastructure
• Unexpected changes to artifacts, build configuration, or repository settings

Security teams should pay particular attention to administrator tokens created around the time of suspicious unauthenticated requests. The real-world attacks observed by watchTowr demonstrate that token minting is a central part of the exploitation path.

Patching alone may not be sufficient for an Artifactory instance that was exposed before remediation. If an attacker successfully generated administrator credentials, those credentials or backdoor accounts can potentially remain usable after the underlying vulnerability has been fixed.

Organizations should therefore inspect historical audit logs and rotate credentials that may have been exposed. The Hacker News recommends reviewing audit activity, rotating affected credentials, and examining connected systems for unauthorized modifications or persistent access.

Incident responders should also review:

• Artifactory administrator accounts
• Access and identity tokens
• Repository permissions
• Federation relationships
• CI/CD integration credentials
• Build-system secrets
• Package and artifact integrity
• Recently changed binaries and container images
• Systems reachable using credentials stored in or accessible from Artifactory

Where compromise is confirmed, teams should consider the potential impact on the broader software delivery chain rather than treating the event as an isolated Artifactory account incident. A malicious administrator may have had opportunities to inspect or alter assets later consumed by downstream development, deployment, or production systems.

The CVE-2026-82329 mitigation process should therefore combine immediate upgrading with credential rotation, account review, artifact integrity validation, and threat hunting across connected CI/CD infrastructure.

The post CVE-2026-82329: Critical JFrog Artifactory Authentication Bypass Exploited in the Wild appeared first on SOC Prime.

HPE has released security updates addressing a maximum-severity remote code execution vulnerability affecting its network fabric management platform. Tracked as CVE-2026-76658 and rated 10.0 on the CVSS v3.1 scale, the flaw can allow an unauthenticated remote attacker to gain administrative access and execute arbitrary commands as a privileged operating-system user.

The vulnerability resides in the SSH daemon used by HPE Networking Fabric Composer, a platform designed to manage and automate data-center network fabrics. Successful exploitation can result in complete compromise of the affected management host, creating a potentially serious risk because the appliance may have privileged visibility into and control over network infrastructure.

CVE-2026-76658 is one of dozens of security issues covered by HPE bulletin HPESBNW05133. Another flaw in the same release, CVE-2026-76657, also carries a CVSS score of 10.0 and can allow unauthenticated attackers to bypass API authentication and gain administrative privileges.

At disclosure, HPE said it was not aware of public exploit code or public discussion targeting the newly patched vulnerabilities. Nevertheless, the combination of remote network access, low attack complexity, no authentication requirement, and complete confidentiality, integrity, and availability impact makes CVE-2026-76658 an urgent remediation priority.

CVE-2026-76658 analysis

The flaw specifically affects the product’s SSH daemon. According to HPE’s CVE description, an attacker can remotely interact with a vulnerable Fabric Composer host without first authenticating and obtain administrative access. Successful exploitation then permits arbitrary commands to run as a privileged user on the underlying operating system, potentially leading to complete system compromise.

The most important details for CVE-2026-76658 are reflected in its CVSS vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. This means exploitation is network-accessible, has low attack complexity, requires no existing privileges and no victim interaction, and can result in high confidentiality, integrity, and availability impact. The scope is also marked as changed, indicating that successful exploitation can affect security resources beyond the vulnerable SSH component itself.

CVE-2026-76658 affects Fabric Composer releases from version 7.0.0 through 7.3.3. HPE’s security bulletin recommends upgrading systems remaining on the 7.3 branch to 7.3.4 or later, while organizations moving to the newer branch should use 7.4.0 or later.

The vulnerability’s location in an SSH service is especially important from a defensive perspective. SSH management interfaces are commonly trusted administrative paths, and compromise at this layer could provide an attacker with direct control over the management appliance rather than merely access to an individual web application function.

Unlike vulnerabilities that require valid administrator credentials or an existing foothold, this issue can potentially be triggered by an external actor who can reach the vulnerable SSH service. Administrators should therefore pay close attention to whether the management interface is reachable from user networks, external infrastructure, or other untrusted segments.

HPE has not publicly documented the precise malformed packet, authentication sequence, implementation bug, or protocol state required to exploit the issue. It would therefore be inaccurate to characterize the flaw as a specific buffer overflow, hard-coded credential, command injection, or cryptographic weakness based solely on the information currently available.

What is confirmed is the resulting security boundary failure: an unauthenticated remote actor can obtain administrative access and execute commands with privileged operating-system permissions. If exploited, an attacker could potentially alter Fabric Composer configuration, access information stored on the management host, interfere with management functions, establish persistence, or leverage the system as a foothold for additional activity against reachable infrastructure. Cyber Security News specifically notes that appliance compromise may allow attackers to change configuration, steal information, or move further into the organization’s environment.

The broader HPESBNW05133 bulletin increases the risk because it contains numerous weaknesses across the API, web management interface, installation components, and underlying operating system. Reported vulnerability classes include authentication bypass, remote code execution, cross-site scripting, arbitrary file write, SQL injection, path traversal, privilege escalation, information disclosure, command injection, and denial of service.

Some of these issues may also be useful in chained attacks. For example, CVE-2026-76657 independently allows unauthenticated remote attackers to bypass API authentication and obtain administrative access, while CVE-2026-19766 can provide privileged code execution from an adjacent network under its required conditions.

The public CVE record was published on September 1, 2026. The exact original discovery date for CVE-2026-76658 has not been disclosed. The CNA metadata records the issue as externally discovered and does not identify the contributor by name, while reporting around the broader HPE bulletin notes that multiple vulnerabilities were also uncovered through HPE’s own security research.

As of September 2, there was no known public CVE-2026-76658 PoC and HPE had not reported active exploitation. The vulnerability was also not listed in CISA’s Known Exploited Vulnerabilities catalog at that time.

The absence of public exploit code should not be interpreted as low risk. A network-reachable CVSS 10.0 vulnerability in an administrative SSH service can become substantially more dangerous once researchers or threat actors determine the precise exploitation technique, particularly when vulnerable appliances are reachable from less-trusted network segments.

There are currently no vendor-published CVE-2026-76658 IOCs associated with exploitation campaigns. Defenders therefore need to focus primarily on version exposure, unexpected SSH activity, administrative behavior, and changes made on the management appliance rather than relying on known malicious hashes, domains, or attacker IP addresses.

Contact Sales

CVE-2026-76658 Mitigation

Organizations should upgrade affected Fabric Composer installations immediately. HPE recommends the following fixed versions:

• Fabric Composer 7.3.4 or later for organizations remaining on the 7.3 branch
• Fabric Composer 7.4.0 or later for deployments using the 7.4 branch

Older releases that have reached End of Maintenance should be considered potentially vulnerable unless HPE explicitly states otherwise. End-of-support versions have not necessarily been evaluated and should not be assumed secure simply because they are absent from the supported-version table.

CVE-2026-76658 detection should begin with identifying every Fabric Composer appliance, confirming its exact running version, and determining where its SSH management interface is reachable from. Any installation running version 7.3.3 or earlier should be prioritized for remediation.

Organizations should also verify whether SSH and web management interfaces are isolated from general-purpose and untrusted networks. HPE recommends placing management interfaces on a dedicated Layer 2 segment or VLAN and enforcing Layer 3 firewall controls to limit which systems can reach them.

To Detect CVE-2026-76658 exploitation attempts or suspicious post-compromise activity, security teams should review appliance, authentication, network, and management telemetry for:

• Unexpected SSH connections from unfamiliar systems or network segments
• Administrative sessions without a corresponding authorized maintenance activity
• New or modified administrator accounts
• Commands executed outside expected administrative workflows
• Unexpected changes to Fabric Composer configuration
• New outbound network connections originating from the management appliance
• Attempts to disable or modify logging and accounting controls
• Unexplained access to managed network infrastructure
• Configuration changes immediately following suspicious SSH activity
• Persistence mechanisms or unexpected operating-system processes on the appliance

These signals are behavioral hunting leads rather than vulnerability-specific signatures because HPE has not published the exact network request or protocol sequence required to trigger the flaw.

Organizations should retain and review historical logs from before patch deployment wherever possible. Updating closes the known vulnerability but cannot determine whether an exposed host was compromised before the fix was installed.

Administrators should pay particular attention to unexplained privileged activity on systems whose SSH services were reachable from untrusted networks. Because successful exploitation can provide administrative control and privileged command execution, suspicious activity should trigger investigation of the entire Fabric Composer host rather than only the SSH service.

If compromise is suspected, security teams should examine administrator accounts, authentication records, configuration history, network-management changes, system processes, persistence mechanisms, and credentials accessible from the appliance. Managed switches and other infrastructure controlled through the system should also be reviewed for unauthorized configuration changes.

The broader CVE-2026-76658 mitigation strategy should combine rapid patching with strict segmentation of management interfaces, firewall-based access restrictions, centralized logging, administrative accounting, and regular review of privileged access.

HPE specifically recommends restricting command-line and web management interfaces to dedicated management networks and using logging and accounting controls to track access and user activity. These measures do not replace patching, but they can substantially reduce exposure to future vulnerabilities affecting administrative interfaces.

Given the maximum CVSS score and lack of authentication requirements, vulnerable systems should not remain reachable from untrusted networks while organizations wait for their normal maintenance cycle.

The post CVE-2026-76658: Critical HPE Fabric Composer Flaw Enables Unauthenticated Remote Code Execution appeared first on SOC Prime.

PaperCut is responding to active attacks targeting its NG and MF print management platforms through a pair of zero-day vulnerabilities that can be chained to achieve unauthenticated remote code execution. One of the flaws, tracked as CVE-2026-81578, is a high-severity authentication bypass that enables a remote attacker to modify sensitive PaperCut configuration without first logging in.

Rated 8.8 on the CVSS v4.0 scale, the vulnerability exists in the web management interface and results from administrative actions being processed before access validation has fully completed. On its own, the flaw enables unauthorized configuration changes. Combined with the critical CVE-2026-82078 unsafe dynamic class-loading bug, however, the attack chain can result in arbitrary Java execution under the security context of the PaperCut Application Server.

The Exploited PaperCut Vulnerabilities have already been observed against customer environments. Huntress detected the first known attack activity on August 26, 2026 and reproduced a complete pre-authentication RCE chain against a standard PaperCut NG installation. CISA subsequently added both CVE-2026-81578 and CVE-2026-82078 to its Known Exploited Vulnerabilities catalog, confirming that the threat has moved beyond proof-of-concept exploitation.

PaperCut now treats all versions of PaperCut NG and PaperCut MF as potentially impacted and has released Emergency Patch Release 3 for versions 24, 25, and 26. The latest emergency update supersedes the previous patches and adds additional hardening after researchers and defenders identified further attack paths against incompletely patched systems.

CVE-2026-81578 analysis

The vulnerability is classified as a missing-authentication or improper access control issue affecting PaperCut’s administrative web interface. Under specific conditions, a specially crafted unauthenticated request can reach backend administrative functionality before PaperCut completes the expected access-control checks.

The important details for CVE-2026-81578 involve the difference between the page presented to the requester and the backend action ultimately executed. Huntress found that a crafted request can reference one page to be rendered in the response while targeting a component or action belonging to another page. PaperCut’s vulnerable authorization logic can validate the rendered page rather than correctly enforcing the authorization requirements of the underlying component.

This allows an external attacker with no valid PaperCut account to interact with administrative functionality and alter trusted server configuration.

CVE-2026-81578 affects PaperCut NG and PaperCut MF. PaperCut’s current emergency advisory conservatively applies to all versions of both products while its incident response investigation remains active. PaperCut Hive and PaperCut Pocket are not impacted, while Mobility Print and Print Deploy server components use separate architectures and are also outside the scope of this vulnerability.

The authentication bypass becomes significantly more dangerous when combined with CVE-2026-82078. That second flaw exists in PaperCut’s database connection utilities and involves unsafe dynamic class loading. The software can instantiate database driver classes using configurable driver names without restricting them to an approved allowlist.

Normally, exploiting CVE-2026-82078 requires high privileges because the attacker needs the ability to manipulate the relevant configuration parameters. CVE-2026-81578 supplies that missing step: an unauthenticated attacker can first modify trusted server settings and then abuse the class-loading behavior to execute arbitrary Java bytecode already available on the application’s classpath.

In practice, that transforms two vulnerabilities with different prerequisite conditions into a pre-authentication RCE chain.

Huntress recreated the chain against PaperCut NG version 25.0.11.75758. In its test, a remote unauthenticated request caused charmap.exe to execute as SYSTEM beneath the PaperCut pc-app.exe Application Server process, demonstrating that successful exploitation can cross from an exposed web interface into operating-system command execution with highly privileged rights.

A working CVE-2026-81578 PoC is now publicly available for the combined CVE-2026-81578/CVE-2026-82078 attack chain, and public exploit references have also appeared in vulnerability databases and security tooling. That substantially reduces the barrier for scanning and exploiting unpatched internet-facing systems.

Real-world attacks were underway even before full public technical details emerged. Huntress observed exploitation in two customer environments, with the first incident occurring on August 26. One attack lasted less than two minutes and executed Base64-encoded reconnaissance commands that decoded to:

whoami & ver

A second incident extended the reconnaissance sequence to:

whoami & ver & tasklist

These commands allowed the attackers to determine the identity under which PaperCut was running, the Windows version, and active processes.

The attackers also delivered malicious Java .class files through the vulnerable server. Huntress recovered one payload as:

lib/Udydn.class

Researchers also observed an unusual in-memory Apache Derby database path ending in:

memory:C:\Program Files\PaperCut MF\server\data\internal\pwn

The second database boot event occurred immediately before code execution, making it a high-confidence forensic artifact for the observed attack chain.

PaperCut’s subsequent investigation shows that attacker behavior has since escalated beyond basic reconnaissance. The vendor describes a second wave against public-facing systems that were not fully patched, with more sophisticated post-compromise activity than what was seen during the first days of the campaign.

Later observed command sequences included domain and session reconnaissance with nltest, quser, and directory enumeration, followed by downloads of legitimate remote-access software. PaperCut documented attackers fetching a SimpleHelp agent and AnyDesk, with SimpleHelp installed as a persistent Windows service named Remote Access Service running as LocalSystem.

The activity shows why the authentication bypass should not be evaluated in isolation. Once chained to code execution, an internet-facing PaperCut Application Server can become an initial foothold for privileged remote access, discovery, persistence, and potentially further lateral movement.

The exact original discovery date has not been publicly disclosed. PaperCut first published its urgent advisory on August 27, 2026 after confirming active customer incidents, assigned CVE identifiers as the investigation developed, and released the initial emergency patch on August 28.

CISA added the vulnerability to its KEV catalog on August 31, 2026, with a remediation due date of September 14, 2026 for affected federal organizations subject to the directive. Known ransomware use is currently listed as unknown.

PaperCut and Huntress have now published useful CVE-2026-81578 IOCs, although defenders should remember that attackers can change payload names, infrastructure, and post-exploitation tools.

CVE-2026-81578 Mitigation

PaperCut’s primary recommendation is to remove PaperCut NG/MF Application Servers from direct internet exposure immediately. If an Application Server is publicly accessible, organizations should restrict its web interfaces to trusted IP addresses using firewall rules, network access controls, a VPN, or another controlled administrative access path. This should be done even when no suspicious activity has been observed.

For supported deployments, administrators should install Emergency Patch Release 3, published September 1, 2026. Release 3 supersedes Releases 1 and 2, so customers do not need to install the earlier emergency packages first. PaperCut recommends that internet-facing systems upgrade again even if Release 1 or Release 2 has already been installed.

The current emergency patches cover PaperCut NG/MF versions:

• 26
• 25
• 24

Organizations running version 23 or older should upgrade to a current supported version rather than wait for a separate emergency patch. PaperCut explicitly recommends upgrading pre-v24 installations to the latest available release.

Administrators should also patch Site Servers and secondary/print servers, not only the primary Application Server. PaperCut states that Mobility Print, Print Deploy servers, User Client software, Print Deploy clients, and the Mobility Print installer are not affected by this incident.

CVE-2026-81578 detection should start by identifying every PaperCut NG and MF Application Server and determining whether it was externally accessible at any time beginning at least August 26, when Huntress first observed exploitation.

To Detect CVE-2026-81578 exploitation or post-compromise activity, defenders should examine PaperCut logs, endpoint telemetry, network records, and filesystem activity for the following indicators:

• Suspicious child processes originating from pc-app.exe or pc-app
• Missing, deleted, or unexpectedly truncated server.log files
• ERROR No suitable driver found for jdbc:no:x
• ERROR DatabaseUtils – Database error looking up cardID: VALUES CAST
• DB URL: jdbc:derby:memory:pwn;create=true
• Database error looking up cardID: VALUES CAST(X’cafebabe
• DB URL: jdbc:no:x DB Driver: <5-char random name>
• Unexpected five-character .class files under <install>\server\lib\
• Corresponding .cmd or .out files under <install>\server\data\content\
• cmd.exe spawned by the PaperCut service
• Execution of whoami, ver, tasklist, nltest, or quser from the PaperCut process tree
• Unexpected SimpleHelp or AnyDesk deployment
• A Windows service named Remote Access Service
• SimpleService.exe running from the JWrapper-Remote Access directory

PaperCut cautions that attackers may delete temporary files as the attack progresses, so the absence of these artifacts does not prove that a system was never compromised.

Organizations should also preserve evidence before upgrading or rebooting an exposed system. Huntress recommends capturing the entire PaperCut server/logs directory, configuration state, process trees, reverse-proxy and firewall logs, DNS and network-flow records, and evidence of recently created services, scheduled tasks, autoruns, or files.

The CVE-2026-81578 mitigation process must go beyond patching when there is evidence of compromise. PaperCut recommends securing existing backups, completely wiping and rebuilding the Application Server, and restoring from a clean backup created before suspicious activity occurred.

Security teams should also review administrative credentials, service accounts, tokens, Active Directory access, and systems reachable from the compromised server. Because the PaperCut Application Server can run with SYSTEM or similarly privileged rights, successful exploitation can provide attackers with substantial post-compromise capability.

PaperCut’s rapid sequence of emergency patches also illustrates why defenders should confirm that they are running the latest mitigation rather than assuming an earlier hotfix is sufficient. Researchers discovered additional bypass paths after the first emergency release, Release 2 added further hardening, and Release 3 subsequently closed additional attack vectors observed in the wild.

Contact Sales

The post CVE-2026-81578: Exploited PaperCut Authentication Bypass Chains to Pre-Auth RCE appeared first on SOC Prime.

An AI SOC (AI Security Operations Center) is a security setup where AI agents do the actual work of a SOC — not just show dashboards. They triage alerts, investigate them, and recommend or take action, while a human stays in charge of the final judgment calls.

That’s different from a SIEM, which mostly collects logs and flags alerts for a person to sort through. It’s also different from SOAR, which just runs fixed, pre-written playbooks step by step. An AI SOC reasons through the problem instead of following a script, adapting to what the evidence actually shows rather than a rigid set of rules.

The category exists for a simple reason: the old way stopped working. Alert volumes are too high, and a huge share of those alerts turn out to be false positives. Analysts spend most of their time chasing noise instead of real threats, and that imbalance only gets worse as environments grow. AI SOC tools try to absorb that noise — pulling context automatically, ruling out the obvious non-issues, and handing analysts only what actually deserves their attention.

One thing worth knowing upfront: “AI SOC” doesn’t mean one specific thing yet. Ask ten vendors and you’ll get ten different definitions — some mean basic alert summaries, others mean full autonomous investigation and remediation. That gap between promise and reality comes up a lot in this article, and it’s worth keeping in mind as you read vendor claims elsewhere.

Traditional SOC Challenges

Before getting into how AI SOC works, it helps to understand the problem it’s actually solving — because it isn’t a minor inefficiency, it’s a structural one. These challenges are also why organizations are increasingly looking to an AI SOC platform to help automate alert triage and investigation.

Large organizations can see over 100,000 alerts a day. Only a tiny fraction — as low as 1–5% — are real threats. On top of that, most security teams juggle ten or more separate tools, each with its own alert format, its own severity scale, and its own console to check. There’s no single view of what’s happening. Just noise, scattered across a dozen different screens, each one demanding attention on its own terms.

This takes a real toll on people, not just process. Around half of SOC analysts say alert fatigue is their top challenge, and most of what lands in their queue turns out to be harmless. That constant grind drives burnout, and burnout drives turnover — in a field that’s already short on skilled people to begin with.

It’s not that analysts are bad at their jobs. It’s that no team, however skilled, can keep up with this much noise by hand. And it’s only getting harder as environments grow more complex and attackers increasingly use AI themselves to move faster.

How Does AI SOC Work

A simple way to picture an AI SOC is as a loop with four steps: See, Understand, Decide, Act.

See — Pull in data from everywhere: logs, tools, even reports submitted by people. Human reports usually need more digging, since they’re less structured than machine-generated data.

Understand — This is where the “AI” part matters most, and where an AI SOC analyst would normally spend hours manually connecting the dots. The system pulls out key details — IPs, accounts, devices — adds context, checks outside sources, and connects related alerts into one coherent case, all without a person stitching it together by hand.

Decide — Based on everything it knows, the system reaches a verdict: true positive, false positive, or inconclusive. That third option matters. It’s an honest “I don’t have enough to be sure,” instead of a forced guess dressed up as confidence.

Act — Take action, or stage it for approval. Open tickets. Follow up automatically. Bring updates back into the case so an AI SOC analyst never has to dig through five different tools just to find out what happened next.

That “Decide” step is where trust is won or lost. A good question to ask any vendor: what happens when the system genuinely doesn’t know? A tool that never admits uncertainty isn’t smarter — it’s just less honest about its limits.

Contact Sales

Benefits of an AI SOC

Done well, an AI SOC changes what analysts spend their time on. Instead of clicking through thousands of low-value alerts one by one, they only see the cases that actually need a human decision.

Here’s what that looks like in practice:

Faster investigations. Context that used to take 20 minutes to piece together by hand, across several different consoles, gets pulled and connected automatically in seconds.

Less wasted time. Fewer false positives means more hours spent on real threats instead of ruling out harmless events over and over again.

Lower burnout. Less repetitive grunt work means people are more likely to stick around, which matters in a field already struggling with turnover.

More consistent decisions. The system reasons the same way every time — no difference between a sharp analyst at 10am and a tired one at 2am after a long shift.

Improvement over time. When analyst feedback loops back into the system, it should get better with every case it closes, instead of staying static like an old-school playbook that never learns.

None of this replaces human judgment, and it isn’t meant to. It’s meant to protect that judgment — so the limited attention analysts have goes exactly where it’s needed most, on the handful of cases that genuinely deserve a closer look.

Why Security Teams Are Turning to AI SOC

There are two honest reasons: necessity and hype. Worth separating them.

The necessity is real. Alert volume keeps climbing. Environments keep sprawling across cloud, identity, and endpoints. Skilled analysts are hard to find and hard to keep. Teams can’t afford to wait for a perfect solution while attackers move faster every year.

The hype is real too. Most “AI SOC” adoption today is still early — some estimates put it as low as 1–5% of the market. A lot of what gets marketed as “fully autonomous investigation” is, in practice, still doing summaries and enrichment. Useful, but nowhere near what some vendors imply.

There’s also a sharper warning here: a “security-tuned” AI model isn’t automatically better at security. In one real test, a model marketed as cyber-specialized flagged almost every harmless session as an attack — a broken tool dressed up as a smart one. A security label means nothing until it’s tested on your own data.

This is why more buyers are pushing back on vendor checklists that just happen to match whatever features that vendor sells. Independent, vendor-neutral scoring — covering data handling, detection, investigation, and response — is starting to replace “trust the demo” as the way people evaluate these tools.

Teams getting real value treat AI SOC as one part of good security practice, not a replacement for it. The teams getting burned are the ones who plug a language model into raw traffic, call it “detection,” and spend weeks chasing the false alarms it creates.

What Does an AI SOC Architecture Include?

Definitions vary, but most AI SOC platforms are built from four layers:

Data ingestion and normalization — Pulling data in from every source (SIEM, EDR, identity, cloud, email) and putting it into one consistent format. Without this step, everything downstream is working with scraps.

A knowledge graph — This connects the dots: which assets matter, which accounts are behaving oddly, which relationships are normal versus not. Without it, the system is just reacting to isolated events — it doesn’t actually understand your environment.

An investigation engine — Combines automation and AI reasoning to explain not just “this looks suspicious” but what happened, why it matters, and how far it spread.

Response and feedback — Staged or automatic remediation, plus a way to capture what analysts correct and feed it back into the system. This part matters more than it sounds — platforms that ignore analyst feedback plateau. The ones that use it keep improving.

One more thing worth mentioning: how the system shows its work. Dumping a wall of raw reasoning on the screen isn’t transparency — it’s just more to read. The better approach: show the verdict and key findings first, and keep the full evidence one click away for when it’s actually needed.

Why AI SOC Rocks

Strip away the marketing, and the core idea holds up: match today’s alert volume with a system that can reason at machine speed, and free analysts to do what actually needs a human — judgment, hunting, and strategy. The fact that most major SIEM vendors now offer some version of AI SOC is a good sign the need is real, not just a passing trend.

The catch: not all “AI SOC” is equal. Some tools summarize. Others actually investigate, decide, and act, end to end, with far less hand-holding required. The teams getting the most out of this treat it as a real decision, not a checkbox — testing vendors on their own data, asking what happens when the system is unsure, and making sure there’s a real feedback loop built into how it’s used.

Done right, AI SOC doesn’t replace a security team. It’s the first real answer, in years, to a workload problem that manual triage was never going to solve on its own, no matter how many analysts you hire or how good they are.

The technology to build this well already exists today. The real question isn’t whether AI SOC will become standard practice — it’s whether teams evaluate it carefully enough to tell the platforms that genuinely deliver from the ones that just talk a good game.

The post What Is an AI SOC? appeared first on SOC Prime.

For security teams, AI has generated both more excitement and more confusion than any technology in the last decade. As threat actors experiment with AI to hone their attacks, defenders are trying to determine which AI investments will help them measurably reduce risk.

Matthew Farmer, Accenture’s Managing Director of Security Operations in EMEA, joined Recorded Future’s co-founder Christopher Ahlberg and CTO and co-founder Staffan Truvé in a recent discussion to discuss the agentic SOC and what it takes to move from “AI theater” to real defense. Read on to see the key highlights from the discussion.

Avoiding the "productivity theater" trap

While AI is demonstrably transforming investigation and decision-making layers in SecOps, there’s a significant risk that organizations are falling into what Farmer calls "AI productivity theater."

"We can all agree that there's great production value around a lot of AI capabilities and AI products," he said. "But there are also organizations that are really struggling to achieve any kind of return on investment on their AI.”

The panel noted that the difference between success and failure doesn’t necessarily have anything to do with being in a regulated or non-regulated industry. It’s more about the ability to move past the theater by defining concrete KPIs.

“A lot of what people want to achieve with AI, we can already achieve with existing machine learning or SOAR automation capabilities,” Farmer said. So rather than simply deploying an AI solution for the sake of being AI-enabled, organizations need to ask whether they’re solving for cost improvement, risk reduction, or speed. They need to understand their KPIs so they can measure their true ROI.

Navigating technical and operational challenges

When it comes to bringing new AI solutions online, the panel noted that SOCs often face administrative, legal, and compliance limitations that eclipse any technical hurdles.

They also agreed that data quality and lack of context — “two sides of the same coin” according to Truvé — remain fundamental challenges.

Farmer noted that, “In the new world of tokenomics, it costs just as much money to troll through poor quality data as high-quality data.” It’s essential that security organizations feed only the best intelligence into their AI tools.

Assessing new risks, from democratization to agentic threats

Farmer said that security organizations used to ask a key question: “Do those [threat actors] with the capability have the motive, and do those with the motive have the capability?” We’re now in a world where non-capable threat actors can use AI to capably launch highly sophisticated attacks.

Threats are also becoming more structural. The panel highlighted "indirect prompt injection"—where agents are manipulated by the very instructions they read—as a new, distinct threat vector.

As companies deploy a digital workforce of AI agents, they should consider applying the same security principles of permissions, monitoring, and accountability to agents that they do to humans. But that may not be sufficient. "One big difference [between an agent and a human] is that an agent can spawn off a thousand clones of itself," Truvé said.

A critical challenge facing security teams is that the current observability space of SIEMs and traditional monitoring platforms isn’t built to track the internal state of an LLM.

"You can observe what ports they talk on, you can write that to a SIEM,” Ahlberg said. “But you’re not observing what’s happening inside the LLM.”

The panelists suggested that rather than relying solely on post-event observability, security teams should rethink how they control agents. Instead of setting up easily bypassed guardrails, security teams need to be better at constraining what each agent can do and ask for.

“You could imagine giving them a budget in terms of compute, communication, and delegation,” said Truvé. “These things run too fast. When you’re observing it, it’s already going to be too late.”

Preparing for the move to autonomous defense

According to the panelists, the shift toward autonomous defense is inevitable. "We can choose to go early, or we can choose to go late,” Farmer said. “But I think the decision is made for us."

However, it doesn’t need to take years to begin realizing big benefits from AI. To do so, security organizations should consider:

• Target high-friction areas, using AI to solve specific bottlenecks where addressable cost is low and ROI is immediate.
• Use outcome-based metrics, measuring success through model accuracy, escalation precision, and scan turnarounds rather than simple activity tracking.
• Assume breach, building defensive resilience that will pay dividends in the future.

On that last point, Farmer said he thinks that as teams grow more resilient, they develop a better appetite for deploying automated solutions — and that in turn strengthens their overall security posture.

The future of defense: Intelligence and speed at scale

According to the panel, the most profound change moving forward won’t just be the technology—it’ll be the velocity coupled with intelligence required for defense. "In three years, the main difference will be speed," Truvé predicted. "Defensive timelines will compress from days to minutes or seconds."

Ensuring security will require organizations to move past traditional constraints as they simply won't have time to manually ingest, analyze, and move intelligence. Taking detection engineering as an example, Farmer noted, “If we have to deliver more detection rules faster, we have to break that linear model between volume, speed, and headcount.” Consequently, SOCs will rely increasingly on high-quality, timely intelligence to enable rapid, automated decision-making.

As this shift occurs, the fundamental unit of work for a security analyst will evolve from handling individual alerts to managing and overseeing the agents that process them. In this new era, the human will remain essential—not as a manual processor of alerts, but as the architect who sets objectives, defines constraints, and monitors the behavior of the agents defending the enterprise.

Watch the full webinar here.

To see how your organization can use the Recorded Future Platform to better defend at machine speed, take our quick interactive tour.

Get more relevant, more accurate answers from Prime Architect by giving your AI agent the context it needs — no more copy-pasting excerpts or describing an incident from memory. In Prime Architect, every chat is a space to work through detection engineering and threat research tasks with AI, whether you’re writing a custom prompt or running one of the built-in Agentic AI tools. Now you can bring your own reference materials into that conversation directly: upload playbooks, incident reports, environment documentation, screenshots, and other reference materials into your chat, and let the AI work from the real source.

Why It Matters

Better context means better output. When an AI tool works from your actual playbook, incident report, or environment documentation, its analysis is grounded in your real data rather than a secondhand summary. You can write your message and attach files together, and the AI agent treats the attached files as context for that message — whether you’re running a custom prompt or one of the purpose-built AI tools in Prime Architect. Instead of retyping the key details of an incident or manually condensing a lengthy report before you can even start your analysis, you simply hand the AI the source document and move straight to the insight.

Flexibility for every workflow. Not every analyst wants to work the same way. That’s why there are three different ways to attach a file — a manual upload button, drag and drop, and clipboard paste — so you can choose whichever fits your current task and habits. Dragging a report straight from your desktop, pasting a screenshot you just captured, or browsing for a file through the upload menu all lead to the same result: your AI agent working with richer, more accurate context.

Built for how security teams actually work. Detection engineers and threat researchers rarely start from a blank page — they start from an existing playbook, a prior incident write-up, environment documentation, or a screenshot of a suspicious event. This feature meets that reality head-on, letting you carry that material directly into your conversation instead of translating it into a prompt by hand.

How to Add a File

There are three simple ways to get a file into your chat message in Prime Architect.

Option 1: Upload manually

1. Click the + icon in the chat input area and select Add Files and Images.

2. Select a file from your device.
3. The file appears in the input area and begins uploading.

Option 2: Drag and drop

1. Locate the file on your computer — for example, in Finder or File Explorer.
2. Drag the file into the chat panel in Prime Architect. You can drop it anywhere in the chat window, including the message history area or the input field.

3. The file appears in the input area and begins uploading.

Option 3: Paste from clipboard

1. Copy an image, screenshot, or file — take a screenshot, copy an image from another app, or select a file in your OS file explorer and press Cmd+C / Ctrl+C.
2. Click into the chat input field to make it active.
3. Paste using Cmd+V / Ctrl+V.
4. The file appears in the input area and begins uploading.

A few things to know: You can attach up to 3 files per message, with a maximum size of 5 MB per file. Supported formats include PDF, TXT, CSV, JSON, PNG, and JPG/JPEG — covering the most common document, data, and image formats used in security workflows. Depending on the size of your files, it may take a moment to process them before they’re ready to be used as context, especially for documents with many images or visual elements.

Make It Part of Your Workflow

Whether it’s a playbook pulled from your files, a screenshot of a suspicious alert, or an incident report you’ve had open all day, getting it into Prime Architect takes just a click, a drag, or a paste. Stop summarizing your evidence — start uploading it, and let your AI agent do the deeper work.

The post Bring Your Files Into the Conversation appeared first on SOC Prime.

Security teams don’t have a data shortage — they have a data flood. A single incident can throw off hundreds of thousands, sometimes millions, of log events, and making sense of them under time pressure is exactly the kind of work that breaks people and tooling alike. SOC Prime built LogTotal to take that pressure off, without asking teams to hand over the raw evidence to do it.

The problem: every “send us the logs” request is a privacy decision

Endpoint events, identity logs, cloud audit trails, syslog, Windows Event Logs, application JSON — this is the raw material of detection, hunting, and response. When something breaks, the first ask is almost always the same: send the logs.

That request used to stay inside a closed environment. Now it rarely does. Logs get attached to vendor tickets, dropped into collaboration tools, uploaded to SaaS analyzers, pasted into AI chat windows, copied into shared workspaces. Each hop widens the circle of people, systems, and jurisdictions that can see the original values.

The risk is easy to miss because logs look operational rather than confidential. In practice, one authentication event can carry a username, a source IP, a workstation name, a session cookie, and a bearer token in an Authorization header. A payment-adjacent log can contain a PAN-shaped number. A Windows file path can leak a home-directory username. A field labeled UserName or x-api-key often holds the value in plain text, even when the rest of the line looks harmless. Under GDPR and similar regimes, most of that counts as personal data — and a leaked token or key isn’t a historical record, it’s a live access path.

Refuse to share the logs and you slow down the investigation. Share them raw and you risk violating policy, contracts, or regulation. Manual redaction doesn’t scale, isn’t consistent across analysts, and often strips out the exact identifiers an investigation needs to correlate events.

This isn’t hypothetical. SOC Prime built LogTotal partly in response to HuggingFace’s July 2026 security incident, in which the team’s attempt to send roughly 17,000 events to frontier AI models was blocked by guardrails — forcing a fallback to a local GLM model with GPU and VRAM requirements most organizations simply don’t have. LogTotal is built to handle that same job — at up to 1,700,000 events — without anyone needing frontier-model access or a private GPU cluster.

Why simple redaction doesn’t hold up

Most redaction approaches fail in one of two directions.

Static masking — turning every IP into the same placeholder, every user into USER — destroys the thing that makes investigation possible: correlation. If ten failed logons all collapse to the identical token, you can no longer tell a single compromised account from a credential-spray attack hitting ten different people.

Plain find-and-replace fails the other way. It misses values in unusual encodings or nested JSON, and it over-redacts things that only look sensitive — version numbers shaped like IPs, UUIDs used as message IDs, well-known non-sensitive hostnames. Unkeyed hashing doesn’t solve it either: a raw hash of a common value can be reversed by dictionary-guessing, and identical unsalted hashes across different organizations can accidentally link unrelated incidents together.

LogTotal was built to avoid both failure modes.

How it actually works

1. Sanitization happens locally, in your browser, before anything is sent anywhere. You can download the sanitized log at any point — you always have a clean copy of exactly what was analyzed.
2. Your files never leave your control unsanitized, and nothing is stored. LogTotal doesn’t retain your logs after analysis, and SOC Prime has no need to — the platform isn’t training on your data.
3. Upload in your native format. LogTotal auto-detects EVTX, CEF, JSON/NDJSON, and syslog — no manual conversion.
4. Your sanitized events are correlated at scale. LogTotal runs them against roughly 1,000,000 detection rules and a dataset of 13,000 labels, then applies Higher Order Sigma Rules and agentic AI correlation to connect related events into a coherent picture — up to 1.7 million events, in under a minute.
5. You get an investigation, not a dump. Results are structured as findings on the LogTotal site, not a wall of raw matches.

However, log sanitization is only the first stage of LogTotal once it’s out of the preview. Coming soon is something even more powerful: sanitized logs checked against tens of thousands of behaviour rules, with matches correlated around Higher Order Sigma rules for active threats.

Where teams can use this

• Incident response with external retainers. Sanitize a log packet with a key you retain. The retainer can still cluster hosts, users, and addresses — and you can map tokens back internally if a specific identity needs to be named in a privileged briefing.
• Vendor support and TAC cases. “The log file that shows the error” is famous for containing environment details unrelated to the ticket. Sanitizing before you attach it cuts accidental disclosure without turning the file into noise.
• Detection engineering and rule testing. Sample logs are how detections get written and validated — and how production identities leak into git history, CI artifacts, and demo environments. Sanitizing fixtures once, with a key shared inside the team, keeps examples correlatable while stripping secrets.
• Pre-SIEM or pre-lake sharing. Not every pipeline needs a commercial processor to redact a batch file. For exports, one-off hunts, and cross-team handoffs, a local sanitizer is the control people will actually use.
• GDPR and privacy reviews. Pseudonymization isn’t a blanket exemption, but replacing identifiers with keyed tokens before a file leaves the organization is a concrete technical measure — one you can point to and describe: what was removed, what was retained, how tokens were generated, who holds the key.
• AI-assisted analysis without exposing raw telemetry. Whether the destination is LogTotal, an internal model, or a restricted vendor environment, the question is the same: does the model need the actual password, or does it need to know a secret was present and the same user touched three hosts?

Try LogTotal

The SOC Prime Platform exists to help security teams anticipate, detect, validate, and respond to threats faster. That mission has never required collecting customer secrets. LogTotal extends it to private event analysis at community scale. 

Security teams should not have to choose between a thorough investigation and a defensible data-handling story. Sanitize first. Correlate on tokens. Keep the key. Analyze the evidence that remains.

Explore LogTotal at https://logtotal.com. 

Join the SOC Prime Platform to improve visibility into threats most relevant to your business. To help you get started and drive immediate value, book a meeting now with SOC Prime experts.

The post LogTotal Public Preview: Free, Private Security Log Analysis in Under a Minute appeared first on SOC Prime.

Starting today, Recorded Future is launching AI Alert Filtering, an AI agent that automatically filters every Alert by relevance before an analyst opens it.

At scale, Alerts surface a lot of intelligence to work through, and the volume is only accelerating as threat actors are using AI to find vulnerabilities, spin up phishing infrastructure, and harvest credentials at a speed and scale that wasn't possible before. AI Alert Filtering turns that same AI advantage back on the problem, automating the first pass of Alert relevance so analysts spend their time on what actually warrants attention.

This gives analysts the benefit of seeing the highly relevant Alerts without giving up control. Customers with early access saw an average reduction in alert volume of around 63%, though results may vary based on rule configuration and use case.

Prioritizing intelligence at scale

Powered by Recorded Future AI, AI Alert Filtering takes on the first pass of prioritization, drawing on the Intelligence Graph® to classify references with the full context of Recorded Future's threat intelligence behind every call, not just the text of the reference itself. It sorts references by relevance, summarizes what came through, and explains its reasoning.

What we built

• High and Low Relevance sorting: Every reference inside a fired Alert is classified against the rule's intent. The High Relevance section loads first. Low Relevance items are still there if you need them; you're just not wading through them by default.
• AI summary at the top of every alert: Each Alert is delivered with a summary covering what came through, so analysts may quickly determine whether it demands immediate attention.
• Custom intent per rule: You can define exactly what the AI should prioritize, beyond the default intent Recorded Future ships with the rule. For example, "this is for ACME Bank, not ACME Center" sharpens results without rebuilding the rule from scratch.
• Optional auto-dismiss for empty alerts: When no references meet the relevance threshold, the Alert may be automatically dismissed instead of landing in your queue. Less to filter out, with the full details retained if you need to review it later.
• No data loss: AI Alert Filtering changes what gets surfaced, not what gets stored. The original, unfiltered Alert details are always available in the Portal.

Figure 1: Relevance sorting

A critical remote code execution vulnerability in Gitea has moved from disclosure to active exploitation less than a month after a patch became available. Tracked as CVE-2026-60004 and rated 9.8 on the CVSS scale, the flaw allows an attacker with ordinary repository write access to plant an executable Git hook and run arbitrary shell commands with the privileges of the Gitea service account.

On August 25, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the exploited Gitea vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, confirming that attacks are occurring in the wild. Federal civilian agencies have been instructed to remediate affected installations by August 28, 2026.

The issue becomes particularly dangerous because Gitea enables open registration by default. Although exploitation technically requires an authenticated account with repository write permissions, an external attacker may be able to create an account, create a repository, and obtain those privileges without possessing any previously stolen credentials.

One publicly reported attack against a vulnerable server resulted in deployment of a dropper exhibiting cryptocurrency-mining behavior. The incident reinforces why the critical Gitea RCE actively exploited in the wild should be treated as an urgent remediation priority for internet-facing self-hosted development infrastructure.

CVE-2026-60004 analysis

The vulnerability is classified as CWE-94, Improper Control of Generation of Code, and resides in Gitea’s diffpatch functionality. The affected API endpoint applies user-supplied patches inside a temporary Git repository. Under vulnerable conditions, an attacker can manipulate this process so that repository-controlled content becomes an executable Git hook rather than an ordinary repository file.

The important details for CVE-2026-60004 center on how Gitea created the temporary repository used to process patches. Vulnerable releases used a bare Git clone, where the repository directory itself acts as Git’s internal data directory. Combined with Git’s patch-processing behavior, specially constructed repository content could therefore reach the hooks directory and become executable.

An attacker with write access can submit malicious patch content to the diffpatch API. By triggering a conflicting patch condition, Git’s three-way processing can cause an attacker-controlled executable file to be materialized as a post-index-change hook. Git subsequently executes that hook during repository operations, resulting in command execution as the operating-system account running Gitea.

CVE-2026-60004 affects Gitea 1.17 and later releases before version 1.27.1. Gitea 1.27.1, released on July 27, 2026, corrects the problem by changing the affected temporary clone from a bare repository to a non-bare repository, preventing attacker-controlled paths from being interpreted as executable Git hooks in the same manner.

Successful exploitation requires repository write access. However, Gitea’s default installation settings significantly weaken that prerequisite: registration is normally enabled, users do not necessarily need administrator approval or email verification, and newly registered users can create repositories. An attacker targeting an unchanged internet-facing installation may therefore be able to satisfy the required permissions simply by creating a new account.

Additional exploitation conditions identified in the technical research include a server-side Git version supporting the relevant three-way fallback behavior, access to the diffpatch endpoint, and a temporary filesystem where the Gitea service can write and execute files. These requirements mean not every vulnerable installation will necessarily be exploitable through exactly the same chain, but default configurations can provide a practical path.

Once arbitrary commands execute under the Gitea service account, the impact extends well beyond a single repository. Depending on how the environment is configured, an attacker may gain access to private repositories, database credentials, OAuth secrets, application configuration, environment variables, CI/CD credentials, package registries, or internal services reachable from the Gitea host.

For organizations using Gitea as part of software development and deployment workflows, this also creates a potential supply-chain risk. Compromise of a source-code management platform can expose proprietary code and deployment secrets and may provide opportunities to alter repositories or use stolen credentials to pivot into CI/CD and production infrastructure.

Security researcher Shai Rod, also known as NightRang3r, discovered and reported the vulnerability. Gitea released version 1.27.1 on July 27, followed by the formal security advisory on July 28. The issue initially had no confirmed exploitation reports, but that changed when CISA added it to the KEV catalog on August 25.

A public CVE-2026-60004 PoC has been available since the vulnerability’s disclosure, significantly reducing the effort required to understand and reproduce the underlying attack technique. Public security tooling has also added detection templates for vulnerable instances, increasing the likelihood that attackers can identify exposed servers at scale.

The Hacker News also documented a real-world incident involving an internet-facing Gitea server with open registration enabled. According to the administrator, the attacker reached the vulnerable service over HTTPS, created the conditions necessary for exploitation, and executed a dropper that consumed substantial CPU resources.

The dropper cleared certain library-related environment variables, searched for processes consuming significant CPU resources, attempted to terminate competing processes, downloaded a payload matching the host architecture, executed it, and then removed the downloaded file. The administrator did not recover enough evidence to identify a specific cryptocurrency miner, wallet, mining pool, or threat actor, so the payload should currently be described as miner-like rather than definitively attributed to a known cryptojacking family.

It remains unclear whether this specific attack caused CISA to add the vulnerability to KEV or whether the agency has observed separate exploitation campaigns. Neither CISA nor the two cited reports has publicly attributed the broader activity to a known threat actor.

No authoritative set of campaign-wide CVE-2026-60004 IOCs has been published. Defenders should therefore rely on behavioral evidence such as suspicious account creation, unusual calls to the diffpatch API, unexpected Git hooks, processes launched by the Gitea service, and anomalous CPU or outbound network activity.

CVE-2026-60004 Mitigation

Organizations running self-hosted Gitea should immediately upgrade to version 1.27.1 or later. Gitea Cloud environments were scheduled to receive the update automatically, while administrators of self-managed installations are responsible for applying the patched release themselves.

Because exploitation is now confirmed in the wild, patching should not be delayed until the next routine maintenance window. CISA’s KEV inclusion provides strong evidence that the vulnerability presents an immediate operational risk, with U.S. federal civilian agencies required to remediate it by August 28, 2026.

Organizations unable to patch immediately should disable public registration where it is not required. Setting registration to administrator-controlled mode prevents an unauthenticated internet user from simply creating an account and repository to obtain the write access necessary for the exploit. This measure reduces exposure but does not fix the vulnerability because existing users with repository write permissions can still reach the vulnerable functionality.

Administrators should additionally restrict repository creation and write permissions, reduce external access to Gitea where possible, and avoid exposing development infrastructure directly to the internet unless there is a clear business requirement.

CVE-2026-60004 detection should begin by identifying all Gitea installations, checking their exact versions, and determining whether public registration was enabled while the server was running an affected release. Internet-facing instances that allowed anonymous visitors to register accounts deserve the highest investigation priority.

To Detect CVE-2026-60004 exploitation attempts and post-compromise activity, defenders should review Gitea, API, operating-system, and network telemetry for:

• – Repeated or unexpected requests to /api/v1/repos/{owner}/{repo}/diffpatch
• – Newly created accounts followed quickly by repository creation and patch operations
• – Shells or unfamiliar processes spawned by the Gitea service account
• – Unusual sustained CPU utilization on Gitea hosts
• – Unexpected downloads or execution from temporary directories
• – New outbound connections originating from Gitea or its child processes
• – Unauthorized repository modifications
• – Unexpected access to application configuration, credentials, or secrets

The presence of these behaviors does not independently prove exploitation, but combinations such as new-account registration followed by repository creation, diffpatch requests, and new child processes should be investigated urgently.

Administrators should also review accounts created while the vulnerable version was exposed. Unknown users, repositories created shortly after registration, and accounts that immediately performed API operations may help identify exploitation attempts that occurred before the server was patched.

The CVE-2026-60004 mitigation process should go beyond installing version 1.27.1 if compromise is suspected. Because successful exploitation provides code execution with the privileges of the Gitea operating-system user, security teams should treat the affected host as potentially compromised and investigate accessible secrets and connected systems.

Incident responders should rotate database credentials, OAuth and API tokens, CI/CD secrets, SSH keys, deployment credentials, and other sensitive material accessible to Gitea where evidence suggests arbitrary code execution occurred. Private repositories should also be reviewed for unauthorized changes, and connected build or deployment systems should be examined for lateral movement.

CVE-2026-60004 demonstrates how a vulnerability in development infrastructure can rapidly evolve from a software bug into an active compromise path. With public exploit information available and confirmed exploitation underway, organizations running vulnerable self-hosted Gitea instances should prioritize both patching and retrospective threat hunting.

CHECK AVAILABLE DETECTIONS

The post CVE-2026-60004: Critical Gitea RCE Exploited to Deploy Miner-Like Payloads appeared first on SOC Prime.

Mexico’s Cybersecurity Plan 2025-2030: Turning Ambition Into Defense

Mexico has no shortage of cyber threats. Ransomware attacks are rising, criminal groups are exploiting stolen credentials and financial malware, and state-linked threat actors increasingly view the country’s government agencies, universities, and critical infrastructure as attractive targets. Mexico’s new National Cybersecurity Plan (hereinafter referred to as “Plan”), introduced in December 2025, recognizes many of these risks. However, it remains uncertain as to whether the government can build the institutions needed to address them proactively.

Mexico is ranked as a "Tier 2" nation in the ITU's 2024 Global Cybersecurity Index, placing it alongside Canada, Ecuador, and Uruguay in the upper ranks, trailing the United States (US) and Brazil, which have reached Tier 1 in the Americas. Despite that standing, Mexico is generally perceived by cyber experts as lagging behind international standards in institutional capacity-building, with international cooperation identified as an area requiring growth.

The question of whether the government can build the proper institutions has become more urgent in the aftermath of the FIFA World Cup 2026, which provided a high-profile stress test for Mexico’s digital defenses. With the tournament over and implementation of the government’s 2025-2030 cybersecurity plan beginning in earnest, Mexico faces a major opportunity to improve its cyber posture.

For this reason, the Plan represents a major opportunity for Mexican authorities to bring the country’s cyber readiness to the next level. Although there have been attempts to advance national cybersecurity policy, they have failed to gain traction. With this new Plan, President Claudia Sheinbaum's administration has committed to full implementation over the course of her term, aided by her party's majority control of Congress.

The Plan lays out a six-phase roadmap designed to gradually build Mexico’s cybersecurity capabilities through 2030, with later phases intended to deepen and institutionalize them.

• The 2025 Foundation Phase established a general framework for governance, risk management, incident reporting, and coordination, as well as initial steps to deepen international cooperation, including Mexico’s formal membership in the Latin America and Caribbean Cyber Competence Centre (LAC4) and a cybersecurity Memorandum of Understanding (MOU) with Brazil.
• The 2026 Expansion Phase, now underway, focuses on translating that framework into institutions through the passage of a new General Cybersecurity Law in Mexico, creation of a National Cybersecurity Operations Center, and integration of federal computer security incident response teams (CSIRTs).
• The 2027 Consolidation Phase would establish a National Cyber Range for red team and blue team exercises.
• The 2028 Maturation Phase would incorporate AI into cyber defense and develop a regional response center.
• The 2029 Leadership Phase aims to position Mexico as a cybersecurity services exporter across Latin America and the Caribbean.
• The 2030 Transformation Phase culminates in the establishment of a permanent Cybersecurity Observatory to track incidents, threats, and emerging technologies.

Threat Landscape

In a recent report, Insikt Group assessed Mexico's threat landscape across six persistent categories:

Ransomware is identified as the dominant threat. From January 2020 through April 2026, Insikt Group documented 223 ransomware incidents involving 64 groups and over 100 victims in Mexico. The top ransomware groups were LockBit, Qilin, CL0P, Kazu, and ALPHV (BlackCat), with government, manufacturing, information technology (IT), and food and beverage as the sectors most heavily impacted.

Cloud Software Group has released security updates for a critical authentication bypass vulnerability affecting NetScaler ADC and NetScaler Gateway appliances. Tracked as CVE-2026-19490 and rated 9.3 on the CVSS v4.0 scale, the flaw can allow an unauthenticated remote attacker to circumvent authentication controls on vulnerable systems configured as gateways or AAA virtual servers.

The Critical Citrix NetScaler Authentication Bypass Flaw is particularly concerning because NetScaler Gateway appliances frequently operate at the edge of enterprise networks, providing SSL VPN and other remote-access functionality. Successful exploitation could give an attacker access to protected services without requiring legitimate credentials or user interaction.

CVE-2026-19490 carries a CVSS vector indicating network-based exploitation, low attack complexity, no privileges, and no user interaction, with potentially high impact to confidentiality, integrity, and availability. These characteristics make internet-facing vulnerable appliances an attractive target once reliable exploitation methods become publicly available.

The vulnerability was disclosed alongside CVE-2026-19489, an 8.8-rated memory overflow issue that can cause unpredictable behavior or denial of service when SIP ALG is enabled within a Large Scale NAT configuration. However, CVE-2026-19490 presents the more severe security risk because it targets the authentication boundary itself.

CVE-2026-19490 analysis

The vulnerability is classified as CWE-288: Authentication Bypass Using an Alternate Path. Rather than breaking a password, stealing a token, or exploiting weak credentials, an attacker can reach an alternate authentication path that fails to enforce the controls expected by the affected NetScaler configuration.

The exact exposure conditions depend on the NetScaler software branch and build. For newer vulnerable builds, exploitation requires a SAML action to be configured. Older builds have a broader attack surface because simply operating the appliance as a Gateway or AAA virtual server can satisfy the vulnerability prerequisite.

Specifically, the affected configurations include:

• NetScaler 14.1-43.56 and later vulnerable builds: exploitable when a SAML action is configured.
• NetScaler 14.1-43.55 and earlier vulnerable builds: Gateway or AAA virtual server configuration is sufficient.
• NetScaler 13.1-61.28 and later vulnerable builds: exploitable when a SAML action is configured.
• NetScaler 13.1-61.27 and earlier vulnerable builds: Gateway or AAA virtual server configuration is sufficient.
• 13.1 FIPS deployments: affected when configured as a Gateway or AAA virtual server.

Gateway configurations that can expose the vulnerable path include SSL VPN, ICA Proxy, Clientless VPN/CVPN, and RDP Proxy. AAA virtual servers are also affected under the conditions specified for each software branch.

CVE-2026-19490 affects supported NetScaler ADC and NetScaler Gateway releases before the vendor’s patched builds, including:

• NetScaler ADC and NetScaler Gateway 14.1 before 14.1-73.32
• NetScaler ADC and NetScaler Gateway 13.1 before 13.1-63.21
• Corresponding vulnerable FIPS and NDcPP releases.

Secure Private Access Hybrid deployments relying on customer-managed NetScaler instances are also exposed and require the appropriate software update. Cloud Software Group has already patched its own managed cloud services and Adaptive Authentication offerings.

The most important details for CVE-2026-19490 relate to the position these systems occupy within enterprise infrastructure. NetScaler Gateway is commonly deployed as the authentication and remote-access layer between external users and internal applications. Circumventing that security boundary can therefore provide an attacker with unauthorized access to services that organizations intentionally keep behind authentication controls.

Unlike vulnerabilities requiring an authenticated account, successful exploitation would not depend on first stealing employee credentials. The CVSS vector specifies no privileges and no user interaction, making exposed appliances potentially reachable directly over the network when the required configuration is present.

What happens after authentication is bypassed depends on the applications and resources available through the affected gateway. An adversary could potentially access protected enterprise services, gather information available to remote users, or use the unauthorized foothold as part of a broader intrusion into the internal environment. The vendor’s severity assessment reflects potential high impact across confidentiality, integrity, and availability.

Administrators can determine whether their systems meet the vulnerability prerequisites by inspecting NetScaler configurations for SAML actions as well as authentication and VPN virtual servers. Relevant configuration elements include samlAction, authentication vserver, and vpn vserver entries.

The vulnerability was responsibly disclosed by Samarth Vashisht of JPMorgan Chase’s penetration-testing team. The exact private discovery and reporting dates have not been publicly detailed in the cited disclosures.

As of August 20, 2026, the vendor disclosure and the two cited reports did not identify a publicly released CVE-2026-19490 PoC or confirm active exploitation in the wild. Nevertheless, the combination of unauthenticated remote access, low attack complexity, and widespread deployment of NetScaler at enterprise network edges makes rapid remediation important before detailed exploitation techniques circulate.

There are also no campaign-specific CVE-2026-19490 IOCs published in the cited disclosures. Defenders should therefore focus on appliance configuration, authentication telemetry, abnormal remote-access behavior, and evidence of unauthorized sessions rather than waiting for known malicious IP addresses, domains, or file hashes.

CVE-2026-19490 Mitigation

Cloud Software Group strongly recommends upgrading affected customer-managed NetScaler appliances immediately. The primary fixed branches are:

• NetScaler ADC and NetScaler Gateway 14.1-73.32 or later
• NetScaler ADC and NetScaler Gateway 13.1-63.21 or later
• The corresponding patched FIPS and NDcPP builds.

Organizations operating Secure Private Access Hybrid with customer-managed NetScaler instances must update those appliances as well. Citrix-managed cloud environments have already received the necessary remediation.

CVE-2026-19490 detection should begin with a complete inventory of externally accessible NetScaler ADC and Gateway systems. Security teams should record software versions and identify which appliances host Gateway or AAA virtual servers and which have SAML actions configured.

Administrators can then prioritize internet-facing systems that simultaneously meet the vulnerable version and configuration prerequisites. Appliances used for SSL VPN, ICA Proxy, CVPN, RDP Proxy, or centralized authentication deserve particular attention because they directly mediate access to internal resources.

To Detect CVE-2026-19490 exploitation attempts or suspicious post-authentication behavior, defenders should review NetScaler, AAA, VPN, SAML, and downstream application telemetry for activity such as:

• Successful sessions with no corresponding expected authentication event
• Access to protected resources without a normal login sequence
• Unusual SAML-related requests or authentication flows
• Sessions established for nonexistent or unexpected identities
• Abrupt increases in unauthenticated requests against Gateway or AAA virtual servers
• New remote sessions originating from unusual geographic locations or previously unseen IP addresses
• Access to internal applications inconsistent with the apparent authentication history
• Unexpected configuration modifications following suspicious remote-access activity

Because the exact exploitation request has not been publicly documented, these behaviors should be treated as investigation leads rather than unique confirmation that the vulnerability was exploited.

Security teams should also preserve historical NetScaler authentication and access logs before upgrading where possible. Patching prevents future exploitation but cannot determine whether an appliance was accessed before remediation.

If suspicious sessions are identified, incident responders should investigate the resources reached through the affected Gateway, review downstream application logs, inspect authentication and SAML activity, terminate suspicious sessions, and rotate potentially exposed credentials or tokens where appropriate.

CVE-2026-19490 mitigation should also include moving unsupported NetScaler installations to supported software branches. Devices that no longer receive normal security updates create additional uncertainty because organizations cannot rely on future fixes for newly discovered authentication and memory-safety vulnerabilities.

Given the critical severity and network-facing role of affected appliances, organizations should treat this as an urgent perimeter-security update rather than waiting for their normal maintenance cycle. Both cited reports warn that NetScaler’s history as a target for scanning and exploitation increases the likelihood that vulnerable systems will attract attention as more technical information becomes available.

CHECK AVAILABLE DETECTIONS

The post CVE-2026-19490: Critical Citrix NetScaler Authentication Bypass Exposes Enterprise Gateways appeared first on SOC Prime.

GitLab has released an emergency security update addressing a critical vulnerability that can allow an unauthenticated remote attacker to modify or delete public projects and user data. Tracked as CVE-2026-19478, the flaw affects both GitLab Community Edition (CE) and Enterprise Edition (EE) and carries a CVSS score of 9.4.

The vulnerability stems from a code injection issue involving a GraphQL directive. According to GitLab’s CVSS assessment, exploitation can be performed remotely with low attack complexity, requires no privileges, and does not depend on any user interaction. These characteristics make vulnerable internet-facing self-managed GitLab instances particularly exposed to automated attacks once reliable exploitation techniques become available.

GitLab released patched versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11 on August 17, 2026, outside its normal twice-monthly patch schedule. GitLab.com and GitLab Dedicated were already running patched software, meaning the urgent remediation requirement applies primarily to organizations operating self-managed installations.

CVE-2026-19478 analysis

The vulnerability exists in GitLab’s GraphQL functionality and, under specific conditions, permits an unauthenticated attacker to inject operations through a GraphQL directive. Successful exploitation can result in unauthorized modification or deletion of publicly accessible projects and user data.

CVE-2026-19478 affects the following GitLab CE and EE versions:

• All releases from 18.2 before 18.11.11
• 19.0 before 19.0.8
• 19.1 before 19.1.6
• 19.2 before 19.2.4

GitLab states that when a security advisory does not specify a particular deployment method, all deployment types should be considered affected. This means vulnerable Omnibus installations, source deployments, Helm-based environments, and other self-managed deployment models should be evaluated and updated.

The most important details for CVE-2026-19478 are reflected in its CVSS vector: network-accessible exploitation, low attack complexity, no authentication requirement, and no need for victim interaction. GitLab rated confidentiality impact as low but integrity and availability impact as high, consistent with the ability to alter or remove application data.

The precise GraphQL directive involved has not been publicly disclosed. GitLab has also not described the specific conditions required to reach the vulnerable code path, which limits the amount of technical information currently available to both attackers and defenders.

This matters because GraphQL is designed to give clients flexible access to application data through structured queries and mutations. In a platform such as GitLab, unauthorized manipulation of GraphQL operations can potentially affect repositories, projects, user-managed resources, and other data exposed through the application’s API layer. In this case, GitLab has specifically confirmed the ability to modify or delete public projects and user data.

The vulnerability was reported by security researcher hiimguardian through GitLab’s HackerOne bug bounty program. The company has not disclosed the original private discovery or report date, so August 17, 2026, when the critical patch was published, is the first confirmed public disclosure date.

As of August 18, there was no publicly available CVE-2026-19478 PoC identified in the cited reporting, and GitLab had not disclosed evidence of active exploitation. The Hacker News also reported that public exploit code had not appeared on GitHub at that point.

That situation can change quickly after disclosure. GitLab normally makes the underlying security issue public on its issue tracker 90 days after the release containing the fix. As a result, deeper technical information about the vulnerable GraphQL behavior may become available around mid-November 2026, increasing the importance of patching long before those details are published.

No vendor-specific CVE-2026-19478 IOCs have been published because GitLab has not reported confirmed exploitation. Defenders therefore need to rely primarily on version assessment, application telemetry, GraphQL request logs, audit events, and unexpected modifications to public projects or user data rather than known malicious IP addresses, hashes, or domains.

GitLab’s emergency release also fixes a second GraphQL vulnerability, CVE-2026-19650, rated 7.1. That issue is a cross-site request forgery weakness in the GraphQL multiplex query handler that could allow an unauthenticated attacker to execute mutations through GET requests, although exploitation requires user interaction. It is separate from the critical code injection flaw but reinforces the importance of deploying the complete security update.

CVE-2026-19478 Mitigation

GitLab strongly recommends upgrading every affected self-managed installation immediately. Organizations should move to one of the following patched releases or any later supported version containing the fix:

• GitLab 18.11.11
• GitLab 19.0.8
• GitLab 19.1.6
• GitLab 19.2.4

Organizations running versions from 18.2 through 18.10 should pay particular attention to the upgrade path. Those branches fall within the vulnerable range but did not receive separate fixed releases, so administrators need to migrate to a supported patched branch rather than waiting for a backport.

GitLab.com and GitLab Dedicated customers do not need to perform remediation for this issue because those environments were already updated by GitLab. Self-managed customers remain responsible for verifying their own application versions and completing the upgrade.

CVE-2026-19478 detection should start by identifying every self-managed GitLab instance and comparing its exact version with the affected ranges. Internet-facing installations and systems hosting publicly accessible projects should receive the highest remediation priority because exploitation does not require authentication.

To Detect CVE-2026-19478 exploitation attempts, security teams should review GitLab, reverse-proxy, WAF, and API telemetry for activity such as:

• Unusual unauthenticated requests to GitLab GraphQL endpoints
• Unexpected GraphQL mutations originating from anonymous sessions
• Sudden modification or deletion of public projects
• Changes to public user data without a corresponding authenticated user event
• Repeated malformed or unusual GraphQL directives
• Large bursts of GraphQL requests from previously unseen sources
• Project deletion or modification events that do not correspond with legitimate administrative activity

Because GitLab has not released the exact exploit patterns, these behaviors should be treated as hunting leads rather than definitive indicators of compromise.

Administrators should also compare existing repositories and project metadata against recent backups or other known-good records. The vulnerability’s primary confirmed consequences involve integrity and availability, meaning unauthorized changes or deletions may be more useful evidence of exploitation than conventional malware artifacts.

The CVE-2026-19478 mitigation process should therefore combine rapid patching with integrity checks, audit-log review, and validation of sensitive project activity. If suspicious modifications are discovered, administrators should preserve relevant logs before restoration, identify the originating GraphQL requests where possible, review associated account and API activity, and restore affected data from a trusted backup.

GitLab says the patched releases introduce no new migrations and should not require downtime for multi-node deployments. However, default Omnibus package upgrades normally stop services, perform the update process, and start them again unless administrators have customized that behavior.

CHECK AVAILABLE DETECTIONS

The post CVE-2026-19478: Critical GitLab GraphQL Flaw Enables Unauthenticated Data Modification appeared first on SOC Prime.

A critical security vulnerability in the popular Forminator Forms plugin for WordPress can allow unauthenticated attackers to upload executable PHP files and potentially take complete control of vulnerable websites. Tracked as CVE-2026-15748, the arbitrary file upload flaw carries a CVSS score of 9.8 and affects Forminator versions up to and including 1.56.1.

Forminator is a widely deployed drag-and-drop form builder used for contact forms, payment forms, polls, quizzes, and file uploads. The plugin has more than 600,000 active installations. SecurityWeek estimated that over 300,000 sites were still running vulnerable releases when the issue was publicly disclosed, creating a significant potential attack surface.

The vulnerability is particularly dangerous because exploitation requires no authentication or user interaction. Under the required form configuration, an attacker can manipulate Forminator’s submission handling, bypass restrictions on dangerous file types, and upload PHP code to the web server. If the uploaded file can execute, the attack can progress directly to remote code execution and complete WordPress site compromise.

CVE-2026-15748 analysis

The vulnerability originates in Forminator’s handle_file_upload() functionality and results from a combination of insufficient file type validation and unsafe handling of attacker-controlled form configuration data. Rather than relying on a single validation failure, an attacker chains several weaknesses in the form submission process to transform ordinary user-controlled data into a forged upload configuration.

Successful exploitation requires a published Forminator form containing both a File Upload field and a Select field. Wordfence found that a Select field can be abused as a carrier for specially crafted nested data because Forminator’s generic request sanitizer allows certain nested values to reach later processing stages.

An attacker can manipulate this data so the Select field effectively masquerades as an Upload record. The forged record can include attacker-controlled values defining the field name, type, and configuration. When the form also contains a genuine File Upload field, Forminator’s upload-processing routine operates on the forged entry and passes the attacker-supplied configuration to the upload handler as though it were legitimate.

The second part of the exploit targets Forminator’s dangerous-extension blocklist. The plugin attempts to remove file types such as PHP, JavaScript, executable files, shell scripts, and other potentially dangerous formats. However, the vulnerable implementation performs exact-key matching.

Wordfence demonstrated that an attacker can provide an alternative extension and MIME type expression that is not recognized by the blocklist but is still interpreted by WordPress as matching a .php file. This allows an executable PHP payload to pass the vulnerable file validation process and be written to the server.

CVE-2026-15748 affects every Forminator Forms release up to and including version 1.56.1. The issue is categorized as CWE-434, Unrestricted Upload of File with Dangerous Type, and its CVSS vector reflects network-based exploitation with low complexity, no privileges, no user interaction, and potentially high impact to confidentiality, integrity, and availability.

There is an additional condition that determines whether arbitrary file upload can immediately become remote code execution. In Forminator’s default configuration, uploaded files are stored in a directory containing an .htaccess file designed to prevent PHP execution.

However, administrators can configure a Custom File Upload Storage root. Wordfence found that this custom directory may be created without the same .htaccess protection because it can first be initialized during a frontend request where the WordPress helper responsible for creating the protection file is unavailable. In that configuration, simply requesting the malicious uploaded PHP file can cause the web server to execute the attacker’s code.

The most important details for CVE-2026-15748 therefore involve both the vulnerable form design and the upload-storage configuration. A site with the affected plugin is not automatically exploitable through the demonstrated RCE chain unless the required File Upload and Select fields are present, while custom upload storage can significantly increase the consequences of successful file upload.

Once PHP execution is obtained, an attacker could deploy a web shell and use it to take control of the WordPress installation. Depending on server privileges and hosting architecture, this could enable modification of site content, credential theft, database access, malware distribution, creation of administrator accounts, persistence, or further movement into the underlying hosting environment. Wordfence specifically warns that arbitrary file upload vulnerabilities of this type can lead to complete site compromise.

The vulnerability was discovered by security researcher daroo and reported through the Wordfence Bug Bounty Program. Wordfence received the initial submission on July 11, 2026, validated the issue and confirmed the CVE-2026-15748 PoC on July 14, and provided full technical details to the Forminator development team the same day.

The developer acknowledged the vulnerability on July 20 and submitted a patch for review. Forminator version 1.56.2, containing the complete security fix, was released on July 31, 2026. The vulnerability was publicly detailed by Wordfence in mid-August.

At the time of disclosure, there were no reports of active exploitation in the wild. CISA’s vulnerability enrichment information also listed exploitation as “none” as of August 18, although it classified exploitation as automatable and the potential technical impact as total.

There are currently no campaign-specific CVE-2026-15748 IOCs such as attacker-controlled IP addresses, domains, or malware hashes published in the cited research. Organizations should therefore focus on behavioral evidence, suspicious uploads, PHP files appearing in upload directories, and unexpected server-side execution rather than relying solely on static indicators.

CVE-2026-15748 Mitigation

Website administrators should immediately upgrade Forminator Forms to version 1.56.2 or later. The patched release was published on July 31, 2026, and fully addresses the arbitrary file upload weakness described by Wordfence.

CVE-2026-15748 detection should start with identifying WordPress installations running Forminator and determining their exact plugin version. Sites using version 1.56.1 or earlier should be treated as vulnerable and prioritized for patching, particularly if public forms include both Select and File Upload fields.

Administrators should also inspect Forminator’s file-storage configuration. Sites using a custom upload root deserve additional attention because the directory may not contain the .htaccess protection that normally prevents uploaded PHP files from executing.

To Detect CVE-2026-15748 exploitation attempts, security teams should review WordPress, web server, WAF, and file-system telemetry for activity such as:

• Unexpected .php, .phtml, or other executable files in Forminator upload directories
• Form submissions containing unusual nested data associated with Select fields
• Suspicious MIME type or extension patterns submitted to file upload functionality
• Direct HTTP requests to recently uploaded PHP files
• New or modified WordPress administrator accounts following suspicious form submissions
• Unexpected outbound connections initiated by the PHP or web server process
• Web shells, obfuscated PHP code, or unfamiliar files appearing under WordPress content directories
• Unexplained modifications to themes, plugins, configuration files, or database records

Because these behaviors can have legitimate or unrelated causes, they should be correlated with Forminator version information and suspicious form-submission activity before being treated as confirmation of compromise.

Organizations should also review historical logs from before the update. Installing version 1.56.2 prevents future exploitation but does not remove malicious files or persistence mechanisms that may already have been placed on the server.

If evidence of exploitation is discovered, incident responders should preserve web and application logs, identify uploaded payloads, inspect the filesystem for web shells and persistence, review administrator accounts and API credentials, rotate exposed WordPress and database secrets, and verify the integrity of core WordPress, plugin, and theme files.

Wordfence states that its firewall’s built-in malicious file upload protection blocks attempts targeting this vulnerability for both paid and free users. However, a web application firewall should be considered an additional defensive layer rather than a substitute for updating the vulnerable plugin.

Considering the vulnerability’s 9.8 severity, lack of authentication requirements, potentially automatable exploitation, and the large number of installations, CVE-2026-15748 mitigation should be treated as a high-priority action for organizations operating internet-facing WordPress websites.

CHECK AVAILABLE DETECTIONS

The post CVE-2026-15748: Critical Forminator WordPress Flaw Enables Unauthenticated RCE appeared first on SOC Prime.