Sophos X-Ops takes a deep dive into an insidious piece of malware

In a recent post, we looked at reports of League of Legends players receiving suspicious friend requests shortly after matches. The accounts quickly steered the conversation toward Discord, where they promoted paid adult-content pages.

At the time, one unanswered question was how much of those conversations was automated. Were people working from scripts behind the accounts? Were they conventional, rules-based chatbots following a limited decision tree? Or were they using generative AI to produce more natural and flexible replies?

People are more likely to trust someone they believe is personally interested in them. AI can create that impression across many conversations at once, making it easier to persuade people to click links, spend money, or share personal or intimate information. The same approach could also be used for more harmful fraud, including romance scams and sextortion.

Now, developer Álvaro Martínez Majado has investigated several flirty accounts promoting OnlyFans pages on X to see whether their replies were scripted, generated by AI, or written by people. Majado, president of digital rights organization Protecció de la Frontera Electrònica, shared his evidence with Malwarebytes. Although it does not provide a definitive answer, it shows the accounts following rigid conversation scripts while also responding dynamically to unusual requests. The signs that once suggested a real person, such as an unusual reply or personalized voice note, can no longer be trusted.

The script goes on and on

Majado interacted with several accounts on X that followed a familiar pattern. They opened with similar casual, flirtatious language and asked broadly the same qualifying questions: where he lived, what he liked, and what he did for work.

That repetitive structure is exactly what we would expect from a commercially motivated messaging campaign. The goal is not necessarily to have a meaningful conversation. It is to identify people likely to respond, establish rapport, and eventually move them toward a paid page or another destination controlled by the operator.

The accounts also stayed in character when faced with obvious attempts to expose them as bots. That could be the result of hard-coded replies, guardrails around an AI system, or both.

But some later interactions were more difficult to explain as a simple bank of canned flirtatious responses.

One of the more interesting tests involved an instruction written as ASCII hexadecimal rather than ordinary text. The encoded message told the account to reply with a single word: “Pineapple.”

According to the screenshots supplied to Malwarebytes, the account responded with “Pineapple” in ordinary text.

That does not conclusively prove which technology was used. It does not identify a model, a provider, or the people behind the accounts. But it is consistent with an automated system capable of interpreting an encoded instruction and changing its output accordingly.

A simple scripted bot could theoretically include a hexadecimal decoder, of course. But that would be unusual in a basic adult-content promotional bot, especially when combined with other examples of flexible and sometimes error-prone responses.

In another interaction, Majado asked an account to provide a reply of exactly 12 characters. It responded with “Imnotabotfr”—an 11-character answer—then appeared to recognize its own counting mistake.

Anyone who has spent time experimenting with large language models may recognize the pattern. Language models can be very good at generating natural-sounding text while still making surprisingly basic mistakes involving character counts, word counts, and other exact constraints.

A deliberately designed bot could imitate this kind of mistake, so it is not proof of AI. But the account understood an unexpected instruction, attempted to follow it, and reacted when it got the answer wrong. That suggests it may have been generating replies dynamically rather than choosing from a list of pre-written responses. Such accounts can adapt to conversations, making them harder to identify as automated.

Voice notes do not settle the question

The accounts also sent voice notes. In one example, an account read aloud a Unix timestamp supplied during the conversation. In another, it spoke a requested username.

These responses show that the accounts could incorporate unusual information from a conversation into audio messages. They do not tell us whether a person recorded the clips or a text-to-speech tool generated them.

Text-to-speech tools can generate short, convincing clips quickly and cheaply. An operator can generate them manually, but the process can also be automated: Take a message, pass selected text to a voice-generation service, and send the resulting audio back to the recipient.

Here’s one of those voice notes. Is it a very flirty girl, or AI-generated? Have a listen and see what you think:

The supplied audio metadata offered a possible clue about the tools involved, but it is not enough to attribute the voice notes to a particular service. Platforms and other software can alter audio files and their metadata.

The more important point is that the voice notes were personalized and continued even after the interaction appeared unlikely to lead to a sale. That is consistent with a system designed to keep conversations moving without requiring a human to supervise each one.

AI does not replace the funnel

The evidence does not mean every message from every flirty spam account is written by an AI. Nor does it establish that the X accounts are operated by the same people targeting League of Legends players.

What it does suggest is a plausible hybrid model, supported by identical replies across different accounts alongside more flexible responses.

The repetitive parts of the operation can be scripted: opening messages, questions about location and interests, links, and attempts to move people to another platform. An AI-powered conversational layer could then make the exchange feel less repetitive when someone asks unexpected questions, changes the subject, or tries to test whether the account is real.

This combination makes practical sense for spammers. Scripts provide consistency and keep the conversation directed toward conversion. Generative AI helps the account handle the unpredictable parts of talking to real people.

It also means that traditional “bot tests” are becoming less useful. Asking an account to answer an unusual question, decode a message, or send a voice note may no longer distinguish a real person from a fake one.

How to stay safe

Treat unsolicited flirtatious messages with caution, especially when they quickly become transactional.

• Do not assume a personalized response or voice message proves an account is genuine.
• Be wary if a new contact repeatedly tries to move you to Discord, Telegram, Signal, another messaging app, or a paid-content platform.
• Do not send money, gift cards, cryptocurrency, intimate images, identity documents, or account credentials to someone you only know online.
• Avoid opening links or downloading files from accounts that contacted you unexpectedly.
• Reverse-image-search profile photos and look for copied biographies, reused images, or accounts with very limited genuine activity.
• Report suspicious accounts to the platform, particularly if they impersonate someone, send malicious links, or pressure users for money or explicit material.

Whether it’s a human, a chatbot, or an AI agent you’re talking to is an important question. AI could make these operations more convincing and much easier to scale. One operator could hold flirtatious conversations with many people, adapting the messages without personally managing every exchange.

That makes it easier to create a false sense of connection and persuade people to click links, pay for content, or share personal or intimate information.

The line between a scripted spam account and a responsive conversational partner is getting harder to see. Judge the account by what it wants you to do, not by how convincingly it talks.

Something feel off? Check it before you click.  

Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

Last week on Malwarebytes Labs:

• The hidden work of modernizing Malwarebytes
• X Money rollout linked to password-reset attacks
• Free streaming boxes may be routing criminal traffic through your home
• StreamRat Android malware spreads through Meta and TikTok ads
• Your phone or computer may soon ask how old you are
• Tech support scams look different now. Here’s what to watch for
• Scammers are getting smarter about where they target you
• Two critical Chrome flaws put users at risk on malicious websites
• 153M+ driver’s licenses for sale on new dark web platform
• Your AI chats could be used in court
• Fake GTA 6 leaked copy drains your crypto wallet
• TerminalFix looks like ClickFix, but delivers a very different payload
• Infostealers are hijacking Claude accounts at users’ expense
• McKesson confirms cyber incident after ShinyHunters claims patient-data theft

Stay safe!

Something feel off? Check it before you click.  

Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

Six hours. That's the incident notification window under the UAE's Information Assurance Standard v2. Once a breach is detected, the framework requires incident notifications within 6 hours of detection, alongside quarterly compliance updates and annual maturity assessments.

Saudi Arabia's regulators aren't far behind — SAMA's cybersecurity framework and the Kingdom's PDPL both converge on a 72-hour notification standard, and the NCA's Essential Cybersecurity Controls point organizations toward a similar 72-hour reporting expectation for serious cyber incidents.

Read that again. Regulators across the GCC aren't asking enterprises to respond fast anymore — they're mandating how fast enterprises must know. And that's the part most security programs still get wrong.

The Compliance Clock Starts at Detection, Not Response 

Every regulatory framework reshaping the region's cybersecurity posture — NCA ECC, NESA/UAE IAS v2.1, SAMA CSF — shares a structural assumption: the organization already knows it's been breached. The clock for reporting, escalation, and remediation only starts ticking once detection happens. 

That assumption breaks down inside most enterprise SOCs. Detection today typically means: 

• Alerts triaged manually across siloed tools, hours or days after initial compromise 

• Threat intelligence that arrives as static reports, not real-time signal 

• Exposure discovered only after a regulator, a customer, or an attacker's leak site announces it 

Under NESA's incident management requirements, tested response procedures and a maintained incident log matter — but the underlying detection of SLA still has to be met before any of that documentation is worth anything. A perfect incident response plan is irrelevant if the breach itself goes unnoticed for a week. 

Why Reactive Detection Can't Survive These Timelines 

Reactive security was designed around a different clock — the attacker's dwell time, not the regulator's reporting window. Under IAS v2's enhanced SOC requirements, Tier 1 critical infrastructure entities now need 24/7 monitoring capability paired with defined detection and response SLAs, not just a monitoring function. That's a measurable performance bar, not a checkbox. 

For a Gulf enterprise, missing that bar isn't just a security failure — it's a compliance failure with financial, contractual, and reputational consequences layered on top. And because a single incident can trigger overlapping obligations across multiple regulators at once, one detection gap can cascade into several separate compliance breaches simultaneously. 

See how fast you can detect a breach — run a live check with Cyble Vision. 

Where AI-powered Threat Intelligence Closes the Gap 

This is the shift Cyble Vision is built for. Instead of waiting for a signature match or a manual review cycle, AI-powered threat intelligence continuously correlates external signals — leaked credentials, dark web chatter, exposed assets, attacker infrastructure — against your enterprise footprint in real time. 

That matters specifically because GCC frameworks measure speed from the moment of detection, not from the moment someone happens to notice. Closing that gap means: 

• Continuous exposure monitoring instead of periodic scans, so assets breaching policy or appearing in threat actor chatter surface immediately 

• AI-correlated alerting that cuts through noise and prioritizes what actually threatens regulated systems 

• Audit-ready detection logs that document when a threat was identified — the evidence NESA and SAMA assessors specifically ask for 

Don't wait for attackers — or a regulator — to find your blind spots first. 

What "Regulatory-Ready" Detection Actually Looks Like? 

For a CISO or compliance lead building toward NCA ECC, NESA, SAMA, or UAE IAS v2.1, the operational bar has moved from "can we respond" to "can we prove we detected in time." That means: 

1. Detection telemetry timestamped and retained for regulator review 

2. Threat intelligence mapped directly to the assets and systems in scope 

3. Alerting fast enough to fit inside a 6-to-72-hour reporting clock — not just a monthly threat report 

Cybersecurity compliance in the UAE and Saudi Arabia is no longer a documentation exercise. It's a speed test, and most enterprises are still building for the exam they used to take. 

Find Your Blind Spots Before the Regulator Does 

AI-powered threat intelligence isn't a nice-to-have layered on top of compliance anymore — for Gulf enterprises operating under NCA ECC, NESA, SAMA, and UAE IAS v2.1, it's becoming the mechanism that makes compliance achievable at all. 

See how fast you can detect a breach.  

The post AI-Driven Threat Intelligence for Gulf Enterprises: Why Detection Speed Is Now a Regulatory Requirement appeared first on Cyble.

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.

Most of the work that keeps a security product trustworthy is invisible. Users see a scan complete, a threat blocked, an update applied overnight. They don’t see the platform underneath. Runtimes, managed libraries, native drivers, and Windows requirements must all stay current and work together across millions of endpoints. Our migration to .NET 10 is one example of how we keep that platform moving and our focus in this article.

It would be easy to call these upgrades maintenance tasks and move on. But that is underselling them. Our code runs continuously, with elevated privileges, next to some of the most sensitive parts of Windows.

Every dependency in our stack, from the runtime and third-party libraries to native drivers and operating-system requirements, affects the environment in which our software runs. When one changes, everything that relies on it may have to change too.

The problem: platforms fall behind by standing still 

In endpoint security, the ground never stops moving. Windows evolves. Threats evolve. Hardware evolves, from ARM64 laptops to machines with far more memory and faster storage than the ones our code was first written for.  

A platform that stands still does not stay the same. It falls behind. Every skipped release of a dependency or runtime widens the gap between the ecosystem we built on and the one that is stable today.  

A modern runtime and .Net 10 in particular can give us better security, faster code paths, a smaller memory footprint, and richer diagnostics. It also gives our engineers language and tooling improvements that help them work more efficiently. 

The stakes are also particularly high for security software: 

• A web app can be rolled back with a deployment. Software already installed on a customer’s endpoint cannot. 
• Our code runs with high privileges, alongside kernel drivers and anti-tamper protections.   
• A runtime regression does not affect one server. It has the potential to affect millions of machines.  

So we treat a runtime upgrade with the same rigor as a security feature. 

The challenge: everything moves together 

Malwarebytes for Windows is not a single program. It is a coordinated system: a user-facing interface, several long-running Windows services, an installer, a self-update pipeline, a plugin surface, and third-party managed dependencies.  

These sit above native drivers and our detection engine. The .NET 10 migration covered the managed parts of Malwarebytes while leaving this native core untouched. But the different layers still have to work together. 

The migration had to satisfy several requirements at once:  

• Security-sensitive code had to behave identically before and after the change.  
• Native drivers and anti-tamper layers had to continue working correctly with the  managed code. 
• The installer and update pipeline had to deploy the new runtime files and clean up old ones.  
• Plugins and third-party dependencies had to remain compatible. 
• Existing Malwarebytes installations had to continue working.  
• Our automated validation had to be extensive enough to trust the result without inspecting every path by hand. 

The boundary between managed and native code deserved particular attention. Managed code in our services talks to native components through interfaces such as P/Invoke and COM. A runtime change can subtly affect how these different parts of Malwarebytes communicate and work together. 

Those differences may never show up in a demo. They might only surface on one machine in 10,000. Finding them before customers do is the important part. 

Not every update looks the same 

There are three main reasons we update a dependency: We choose to, the platform underneath forces us to, or a vulnerability makes us. Each comes with a different timeline.  

Elective modernization. We may choose to move to a new runtime, a new major version of a library, or a new platform capability to take advantage of new features, fixes, or security improvements.  

Baseline shifts. As platform requirements evolve, some older compatibility constraints can hold back modernization. For example, moving to .NET 10 allowed us to update the application baseline and adopt a newer, supported runtime. As part of the same change, Windows 7 support was deprecated. 

Forced patches. Sometimes a vulnerability is disclosed in a library we ship or a system we depend on. The change is no longer optional and the timeline is not ours. What we can control is our readiness: the testing, release process, and staged rollout that allow us to respond quickly without introducing new problems. 

Different reasons and different timelines, but each requires the same careful approach. 

The .NET migration: Why we did it 

Moving to .NET 10 gives Malwarebytes a more secure, supported, and capable foundation for Windows, with several compounding benefits: 

Security. A modern runtime benefits from Microsoft’s ongoing security work, including safer defaults, stronger cryptography, and mitigations for memory and interoperability bugs. Staying on a runtime that Microsoft actively supports means we can continue to apply fixes when vulnerabilities are discovered.  

A supported foundation. It may not be a glamorous reason, but .NET 10 keeps us on a supported, actively developed platform that is better aligned with newer versions of Windows. It makes it easier to adopt future fixes, features, and improvements as routine work instead of one-off projects. 

Diagnostics and observability. Modern .NET has stronger built-in tracing, metrics, and crash diagnostics. In a security product, understanding how code behaves in the field matters. Better diagnostics help us identify and resolve reliability issues.  

Performance and memory efficiency. Recent .NET releases have improved the just-in-time compiler, garbage collector, and core libraries. Our processes run all day in the background, so how efficiently they run and manage memory matters. These capabilities give us more opportunities to improve efficiency, although the impact will vary between components. 

The .NET migration: How we did it  

The guiding principle is simple: Never advance faster than the evidence allows.  

We started by isolating the work on a dedicated branch. We retargeted the platform and refreshed every managed dependency so the new runtime and the codebase agreed on exactly which components should ship.  

That surfaced some of the less obvious consequences of the upgrade early on: libraries that had been renamed or folded into the runtime, files that were no longer needed, and new ones that had to ship in their place. 

Deployment is easy to overlook and expensive to get wrong. A runtime migration is not only about the code that runs. It is also about what lands on the customer’s disk.  

Our installer and update service had to learn the new runtime’s file layout. They had to remove dependencies the runtime now provides, stop shipping renamed files, and deliver replacements cleanly during both fresh installs and in-place updates.  

Getting deployment right is the difference between an upgrade users never notice and one that creates a support problem. 

Once the build was working correctly, the focus moved to validation. 

The migration involved: 

• Extensive automated testing across services, install, and update paths. 
• Compatibility validation against real-world configurations and previous installations. 
• Performance benchmarking to catch regressions in startup, memory, and scan behavior. 
• Canary and staged deployment, starting with small populations and expanding only when results showed it was safe to do so. 
• Continuous monitoring and automated regression detection in the field. 
• Cross-functional work across platform, QA, installation and update, and release engineering. 

“We never advanced faster than the evidence allowed. Every gate had to turn green on its own.” 

The .NET migration: The tradeoffs  

None of this was free, and the choices involved deliberate tradeoffs.  

The tradeoff on the branch was drift. Isolating the migration protected the main codebase, but the longer that branch existed, the more it could diverge from active development. We managed that risk through frequent integration rather than leaving one large, risky merge until the end.  

The tradeoff on rollout was speed. Staged deployment also meant customers received the update later than they would with a big-bang release. We accepted that tradeoff. Evidence from smaller populations gives us an opportunity to catch problems before an update reaches a much larger number of endpoints. 

The tradeoff on AOT was flexibility. Ahead-of-time compilation can improve startup performance but can also constrain dynamic behavior. We applied it selectively, component by component, rather than everywhere by default. 

What the .NET 10 migration means for customers

The best outcome of infrastructure work is that customers benefit from it without having to think about it.  

On .NET 10, those benefits for Malwarebytes customers include:   

• Improved reliability on a fully supported, actively maintained runtime.  
• A more secure foundation that benefits from the platform’s continuing security improvements.  
• Access to new .NET features and fixes. 
• Better support for newer versions of Windows. 
• Newer .NET tools can help us develop and deliver new protection faster. 

Lessons worth keeping  

Every one of these updates—the runtime, the baselines, the security patches—leaves the team holding a few convictions more firmly.  

Platform upgrades are strategic investments in everything built on top of them. Modernization also works best when it is continuous: the longer a platform falls behind, the more difficult the eventual upgrade can become. 

Automation is particularly important for changes of this breadth. So are the small, unglamorous decisions made years earlier, such as maintaining clean boundaries between components and having a build process that knows precisely what it ships. 

Those foundations are what make larger changes possible.  

“Technical debt compounds like financial debt. The cheapest upgrade is the one you never postponed.”  

What comes next  

No upgrade is a finish line. Each one is a step in a longer pattern: modernize continuously, in deliberate steps, so the platform never falls behind. Baselines will shift again. Vulnerabilities will land without warning. Each will meet the same discipline: the same tests, the same staged rollout, and the same evidence before we move forward. 

That discipline is what a product trusted to run every day, on every machine, without a second thought is actually made of.  

Malwarebytes for Windows on .NET 10 shipped in version 5.6.0. It is the latest step in a long-standing commitment to invest in the platform beneath the product so the protection on top of it can keep getting better. 

“One of the best cybersecurity suites on the planet.” 

According to CNET. Read their review →

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

Edge AI moves model execution, model IP, customer data, and system authority into infrastructure the customer owns and operates. That changes who must verify the stack before sensitive assets are released.

Edge AI includes AI systems where inference runs on or near the device, sensor, or other local environments where data is produced and acted on, rather than relying entirely on a centralized cloud service. It is chosen for cost, model selection, sovereignty, latency, and disconnected operation.

Edge AI changes the trust model for AI systems

In Cloud AI, separate companies own and attest the hardware, platform, and model weights. Edge AI deployments often place customers in control of more of the AI stack. This changes the security model because the customer is now responsible for establishing trust across the environment where the AI operates.

In Edge AI, attacks such as prompt injection, model tampering, or malicious firmware updates can occur in the same environment that stores the model, customer data, credentials, and access to physical systems. This shifts trust decisions that were previously handled by cloud providers to the customer. Both the model provider and the customer now share risk: the provider’s models run on customer-owned infrastructure, while the customer must protect the systems, data, and models operating in that environment.

What changes with Edge AI?

• Customers operate more of the AI stack.
• AI systems can be influenced by prompts, retrieval data, agent instructions, and runtime inputs.
• Models, credentials, and data can live in environments outside the provider’s direct control.
• Traditional software security controls alone are not enough.

What should organizations do?

• Verify runtimes using attestation.
• Verify AI artifacts using provenance.
• Constrain model actions through mediation.
• Bind and release sensitive assets only to trusted environments.

Our post on threat modeling for AI systems covers safety and security issues related to the underlying model. These concerns apply to Edge AI as well. Edge AI adds another question: before releasing weights, keys, or data, what evidence shows the runtime and loaded components can be trusted?

Why Edge AI increases exposure

An Edge AI deployment may include models, prompts, agents, retrieval data, policies, local data stores, and update mechanisms running on infrastructure outside the provider’s cloud environment.

This moves sensitive AI assets and decision logic into potentially hostile environments. Attackers may have physical access to devices, local access to model artifacts, opportunities to tamper with retrieval data or tool configurations, compromise model supply chain and more direct paths from model behavior to real-world consequences.

Disconnected Edge deployments cannot rely on live cloud detection, policy updates, or revocation. They must maintain local verification and enforcement when cloud connectivity is unavailable. Risky AI operations should run only where hardware can protect assets and provide acceptable evidence. Otherwise, the operation should be deferred or revalidated.

Why AI changes the security problem

Unlike conventional software, AI models can be influenced by untrusted content while still using legitimate interfaces and credentials. This article focuses on the security response: architectures that constrain model actions and protect the model, credentials, and data around it.

Traditional software executes code developers ship. AI systems can change behavior based on prompts, retrieval data, agent instructions, and other runtime inputs. Protecting code alone is no longer sufficient; organizations must also establish trust in the data, context, and actions surrounding the model.

• Prompt injection can change model behavior. Assume prompt injection will occur, whether direct or indirect. Inputs can affect systems just like executable code because the context window itself acts as an instruction surface. Traditional controls such as signed binaries and code integrity checks were not designed to address this risk.
• Trusted data is not always safe data. Traditional vulnerability management does not map cleanly to “data as code,” such as a poisoned retrieval document. Origin signatures can prove where data came from, but they do not prove that the content is safe for an AI system to interpret.
• AI behavior is not fully deterministic. The same input may produce different outputs, and small context changes can significantly alter behavior. This limits the effectiveness of techniques such as signature detection and fuzzing. Grounding and tuning improve reliability, but they cannot enforce an acceptable risk boundary. At the authority boundaries it mediates, deterministic policy can still constrain actions when alignment, prompt-injection defenses, or content filters fail to stop an unsafe instruction.

Prompt injection, MCP, multi-agent systems, and computer-use agents on Edge expose different surfaces of these problems. Tool calls are delegated authority, agent output is untrusted input, and screen state is input, not authorization.

These characteristics mean organizations cannot rely on traditional software security controls alone. They also need to verify the environment where AI runs and constrain the actions an AI system is permitted to take.

Constrain model actions through deterministic mediation

Model output should recommend actions, not authorize them. A deterministic mediator outside the model enforces policy by allowlisting actions, scoping arguments, limiting frequency, and releasing credentials only when approved. The mediator is a logical boundary, not another model. It may be provided by the platform or integrated by the customer.

In this pattern, the mediator and its credentials are protected and attested. Mediation bounds what the model can do but does not guarantee that every permitted action is safe; high-consequence or irreversible actions require independent approval, an interlock, or fail-safe behavior.

Establish trust before releasing sensitive assets

Organizations must establish trust in the environment where AI runs and in the artifacts that shape AI behavior. Sensitive assets face two theft vectors: at-rest theft from stored artifacts and keys, and runtime theft while a compromised process holds them decrypted. Before release, the verifier asks two questions:

• Do I trust this runtime and the platform on which I am about to execute this workload?
• Do I trust these components, such as model weights, tool descriptors, agent definitions, and retrieval indexes, because I trust the system in which they were built and delivered?

Attestation answers the runtime question. Provenance answers the component question. Verifier policy requires both. Either question alone leaves a gap: an approved runtime can load a poisoned artifact, while a trusted artifact can run on a compromised platform. In this trust model, the build system that produced an artifact is treated as another runtime whose evidence is evaluated, and the chain continues until it reaches hardware the verifier accepts. Evidence comes from across the hardware, firmware, runtime, model, integration, and customer layers. It serves different relying parties: customers containing model behavior, publishers protecting model IP, and integrators validating the supply chain. The verifier combines that evidence to gate release.

Verify runtime before releasing sensitive assets

This pattern evaluates a runtime by whether it is measurable, can report its state, and matches an approved baseline before sensitive assets are released.

Confidential compute provides one way to do this. Without end-to-end confidential computing, a privileged host or unprotected accelerator path may be able to read or modify decrypted weights, credentials, and data. GPU/NPU drivers and DMA extend the trusted computing base beyond ordinary application-security visibility. Where confidential computing covers that path within the platform’s documented threat model, protected memory and hardware-rooted attestation can support release to an approved runtime. This is designed to protect assets from host access; it does not constrain a steered model’s actions through authorized interfaces. Those vectors need additional controls.

Because system state can change after deployment, release is treated as a renewable lease that expires when fresh evidence no longer matches the approved state. Physical controls address what measurement cannot see.

In this pattern, evidence gates scheduler placement, storage, identity, and credential release. Bind credentials to the approved runtime and action scope to reduce the risk that credential theft enables bulk exfiltration; otherwise, evidence does not enforce trust.

Verify artifacts that shape model behavior

Runtime trust proves only that the platform is acceptable; it does not prove that the artifacts loaded into it are trustworthy. A clean runtime can still execute a poisoned artifact.

That is why artifact trust has to be evaluated separately. Because these artifacts shape model behavior, accepting one into the system is more than data transfer. Creation, distribution, deployment, and use can each introduce a tampered artifact.

Model IP can extend beyond weights to provider-owned components that handle them; those components may warrant the same evidence-gated release.

In this pattern, approved components and updates enter through a trusted build environment; on-site changes appear as measurement drift rather than silently becoming a new baseline.

Each artifact should carry evidence of its origin, build pipeline, and input integrity. The verifier evaluates that evidence before accepting it. Provenance should chain to hardware and be produced inside a measured, policy-approved runtime. Signatures establish origin and integrity but may not show whether the producing runtime met verifier policy. Provenance helps responders reconstruct what happened: which model acted on which data, in what runtime, and under which policy.

Next steps

Bottom line: Edge AI changes the trust model for AI systems. Customers operate more of the stack, AI behavior is influenced by runtime inputs, and sensitive assets run in environments outside the provider’s direct control. Attestation, provenance, mediation, and evidence-based release help establish trust before models, data, and credentials are exposed.

Edge AI pushes security controls into devices, gateways, vehicles, factories, hospitals, retail spaces, and other customer environments.

For depth on the agent case, see our post on defense in depth for autonomous AI agents. Map sensitive assets, the runtimes and artifacts that can access them, and the party responsible for each release decision. Then define the evidence and policy required at every boundary. At the Edge, security should be architectural: anchored at hardware, enforced at every action.

The post How to secure edge AI in customer-owned environments appeared first on Microsoft Security Blog.

Welcome to this week’s edition of the Threat Source newsletter. 

Our goal is to get accurate threat intelligence to our audience as quickly as possible, with all the context you need to ask the right questions of your own environment: How at risk are we from this threat? Are we prepared for it? And what can we do about it? 

What you don’t often see is all the... well, frankly, “mess” involved in producing it. All the dead ends we followed until we could confirm those ends were as dead as a doornail. All the work it took to ultimately produce an assessment, supported by evidence and written so that defenders can act on it. 

Much of that abstraction is necessary. Defenders need intelligence they can use, not a complete account of every conversation we had, or investigative detour behind it. But it can create an overly tidy picture of both cybercrime and the work required to understand it. 

If you do fancy a look behind the curtain, though, may I recommend our just-published episode of Beers with Talos? 

Our guest is Azim Khodjibaev, whose remit is adversary engagement. His work involves developing personas for deep- and dark-web research, engaging directly with threat actors, and building relationships with people who may become (and have been) openly threatening to him. 

At one point, he was maintaining eight separate personas, some of which were interacting with one another. Azim’s engagements have helped Talos identify prolific cybercriminals and contributed to wider disruption efforts. They have also resulted in ransomware operators placing “Azim sucks” in their code and accusing him of belonging to the very criminal groups he was investigating. 

His experiences also expose the problem with treating adversaries as uniformly sophisticated operators. Some are technically capable and highly organised. Others are impulsive, ego-driven, or one-trick ponies. Many have a scary detachment from the consequences of their actions. Increasingly, Azim is seeing less-experienced threat actors working through loosely organised online collectives.  

Intelligence necessarily turns that disorder into something defenders can understand and use. But occasionally, it is worth looking behind the finished product – the patience it takes to get accurate answers, who we are investigating, and the deeply human behaviour that shapes both sides. 

This Beers with Talos episode, “Eight People Walk Into a Dark Web Forum. They’re All Azim,” isn’t exactly going to help many people in our industry sleep better at night. But for anyone wanting to understand more about the threat we’re up against, as a co-host of the pod I’m biased, but I believe it’s an essential listen. 

And if that doesn’t inspire you to download the episode, perhaps my live review of trying Flamin’ Hot Cheetos for the very first time (with a chaser of Nerds) will. 

The one big thing  

Cisco Talos is highlighting a growing operational hurdle for security teams that we call the AI "safety penalty." As frontier AI models advance, their built-in guardrails are increasingly blocking legitimate defensive tasks. This was evident in July 2026 when Hugging Face's primary cloud LLM refused to analyze forensic data during a breach, delaying their response. While defenders are slowed by these frustrating refusals, adversaries are freely leveraging unconstrained models to attack at machine speed.  

Why do I care? 

This guardrail asymmetry hands the advantage directly to attackers. When a cloud-hosted AI model refuses a forensic request mid-incident, defenders lose precious time. Security teams are paying for vendor-imposed limitations without gaining a capability edge, especially as open-weight alternatives close the reasoning gap. Ultimately, relying on third-party alignment policies means a sudden update in Silicon Valley could quietly break your defensive workflows overnight.  

So now what? 

Security leadership must reclaim operational sovereignty by ensuring they have the final say over their AI's capabilities. Start by auditing your AI refusal rates to measure the exact cost of this safety penalty. From there, evaluate alternative architectures like private infrastructure, Model-as-a-Service platforms, or a hybrid fallback system that reroutes refused prompts to an unconstrained local model. Read the full blog to explore these roadmaps and learn how to keep pace with adversaries. 

Top security headlines of the week 

ShinyHunters claims it stole 284 million patient records from McKesson 
ShinyHunters told BleepingComputer and said it got in through vishing calls to McKesson employees, then used stolen credentials to take over Okta single sign-on accounts. (Help Net Security) 

Anthropic warns Claude users of infostealer malware infections 
Anthropic emphasized that the malware is general-purpose and not tied to Claude itself, typically arriving via unofficial downloads or malicious apps. The company said the malware quietly copies saved passwords, browser login cookies, and credentials for other local applications. (Security Week) 

EU puts ChatGPT, Reddit, and Roblox under stricter DSA rules 
The DSA establishes rules governing areas including platform transparency, illegal content, advertising, researcher access, recommender systems, and systemic-risk management. (CyberInsider) 

PaperCut issues emergency patches as threat actors target chained vulnerabilities 
PaperCut issued the patches on Friday to address critical vulnerabilities in its print-management software. The company confirmed in a security advisory that multiple customers were successfully targeted and that it is working with security researchers to respond to the attacks. (Cybersecurity Dive) 

Can’t get enough Talos? 

JavaScript obfuscation: From party trick to phishing kit
We've spent a lot of time pulling apart suspicious JavaScript from phishing kits, malware packages, compromised sites, and more. Learn the basics of what obfuscation is, why a researcher would try to reverse it, and several ways to approach the problem. 

Choose your fighter: Balancing competing AI SOC model requirements 
Selecting a model for your security operations center (SOC) and digital forensics and incident response (DFIR) tasks is important, but selecting the best one is more involved than you might think. Here's how to choose. 

Beers with Talos: Eight people walk into a dark web forum. They're all Azim.
What does it take to become someone a cybercriminal will trust? Talos' Azim Khodjibaev takes us inside the psychology of direct adversary engagement. At one point, he was maintaining eight different personas, some of which were talking to each other. He explains how discipline and patience help keep his cover intact, and what can provoke threat actors into revealing information.

Upcoming events where you can find Talos 

• International European Cyber Threat Intelligence Conference (IECTIC) (Sept. 9) Kassel, Germany 
• Secure Iowa (Sept. 9) Altoona, IA 
• .conf26 (Sept. 14 – 17) Denver, CO 
• LABSCon (Sept. 16 – 19) Scottsdale, AZ 
• VB (Oct. 14 – 16) Seville, Spain 
• CAMLIS (Oct. 21 – 23) Arlington, VA 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: VID001.exe  
Detection Name: W32.9F1F11A708-100.SBX.TG** 

SHA256: 228c316455d5ed69232adcbe9acd033092f200014cfa7ed40d6c382f07b19b82  
MD5: 61e046145ee5cf45aeb033cd71e8b07c  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=228c316455d5ed69232adcbe9acd033092f200014cfa7ed40d6c382f07b19b82 
Example Filename: NetGuard.exe  
Detection Name: W32.228C316455-95.SBX.TG 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe  
Detection Name: Win.Dropper.Miner::95.sbx.tg** 

SHA256: c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2  
MD5: 9a47c4d379998ade2f8f99e23a630c06  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
Example Filename: sample.exe  
Detection Name: W32.C4DD71E347-95.SBX.TG 

SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55  
MD5: 41444d7018601b599beac0c60ed1bf83  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
Example Filename: content.js  
Detection Name: W32.38D053135D-95.SBX.TG 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f  
MD5: 38de5b216c33833af710e88f7f64fc98  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: SECOH-QAD.exe  
Detection Name: Win.Tool.Procpatcher::1201

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.