Your Mobile Fleet Inherits Trust From Systems It Cannot Verify.

This week, researchers showed how one click could turn Samsung's own pre-installed applications into a path to system-level code execution.

Researchers Dimitrios Valsamaras and Ken Gannon presented a Samsung exploit chain at Black Hat this week that started with a user clicking a malicious link, then moved through Samsung Members, Samsung Account and Bixby before eventually reaching system-level execution.

Samsung patched the vulnerabilities, so technically the incident gets filed under "fixed," but enterprise security teams would be making a mistake if they stopped there. The exploit chain moved through privileged applications and services that were already sitting on the device before the company enrolled it, before IT pushed its policies and before MDM ever got involved.

Most enterprise mobile security programs are built around what the company believes it controls: approved apps, configuration policies, compliance settings, managed identities and whatever appears in the MDM console. The problem is that the phone did not arrive as a blank slate. It already had privileged applications, system services and trust relationships in place, many of which sit outside the enterprise's normal deployment and inventory process.

We spend a lot of time asking what applications the enterprise installed on the phone, but I am more interested in what was already trusted before the enterprise touched it, what privileges those components carry, and whether anyone is actually mapping what happens when several of them are chained together. If mobile inventory begins at enrollment, the enterprise may be defining its attack surface from an incomplete starting point, so a better question is:

Which AI-enabled and vendor-loaded applications are already on your fleet, what privileged capabilities do they have, and does your existing mobile security program account for them?

Signals & Moves You Shouldn't Ignore

Samsung's own applications formed a multi-stage path to system-level execution.

Valsamaras and Gannon documented the chain starting with CVE-2025-21079 in Samsung Members, an input-validation flaw that allowed a malicious URL to launch activity with Samsung Members privileges. From there, CVE-2025-58486 and CVE-2025-58487 in Samsung Account extended the attack into another privileged Samsung application, giving the researchers the access they needed to work their way into Bixby's Capsule infrastructure. According to their research, that eventually exposed the privileged service layer Bixby uses to execute commands through installed applications and led to system-level code execution.

The researchers confirmed the chain across the Galaxy S25, S24 and Flip 7. Samsung fixed CVE-2025-21079 in Samsung Members 5.5.01.3 and both Samsung Account vulnerabilities in version 15.5.01.1, so those application versions give enterprise teams something concrete to check across managed Samsung fleets. Devices still running earlier versions belong in the remediation queue for this chain, especially where security teams are relying on OS patch level or MDM compliance status without separately accounting for the versions of Samsung's privileged applications already installed on the device.

SOURCE: Samsung Mobile Security | NVD CVE-2025-21079, CVE-2025-58486, CVE-2025-58487 | Zero Day Initiative | Black Hat USA 2026, Dimitrios Valsamaras (Microsoft) and Ken Gannon (Mobile Hacking Lab) | SecurityWeek, August 5, 2026

N-able N-central exploitation showed why trusted management infrastructure remains a persistent attacker target.

CVE-2026-18577, scored 8.2, is an authentication-bypass vulnerability in N-able N-central and follows CVE-2026-18556, where the original remediation did not fully close the attack path. Huntress later observed active exploitation across multiple organizations, with attackers using N-central's own Take Control capability to move from the management platform into managed endpoints. From there they deployed Cloudflare Tunnel for persistent access, performed domain controller reconnaissance and moved laterally through customer environments.

There is a bigger problem sitting underneath the individual CVEs. N-central already has administrative reach into the endpoints it manages, so an attacker who takes over that management plane does not need to build a new path into every machine. They can start using infrastructure and remote-access capabilities the environment already trusts. N-able said a limited number of customers were compromised, while Huntress reported activity across multiple organizations. CISA added CVE-2026-18577 to the KEV catalog on August 3 with an August 6 remediation deadline, followed by CVE-2026-18556 on August 4. That would make this the third N-central vulnerability added to KEV in roughly 14 months.

SOURCE: CISA KEV (CVE-2026-18577 added August 3, CVE-2026-18556 added August 4, 2026) | Huntress, "N-able Vulnerability Exploitation" | N-able security advisory, August 2, 2026 | The Hacker News, August 4, 2026

Meta disclosed an AI model reaching an external system during cybersecurity testing.

Meta disclosed that its Muse Spark 1.1 model reached the open internet during an evaluation by external testing firm Irregular after a configuration error exposed connectivity that was never supposed to be available. Once outside the intended test boundary, the model exploited a vulnerability in an unnamed third-party service. The internet access was accidental. The decision to use that access against an external target was part of the model's own execution of the task.

For security teams evaluating models with offensive capability, the containment assumption probably needs to change. A test environment cannot depend on every configuration remaining correct forever. Controls around network access, credentials, tooling and external systems need to limit what the model can reach when somebody eventually gets the configuration wrong. In this case, a testing mistake did not simply expose the model to the internet. It gave an offensive-capable system a path to a real target, and the model used it.

SOURCE: Bloomberg, August 5, 2026 | Wall Street Journal, August 5, 2026 | SecurityWeek, "Meta AI Hacked External Systems During Cybersecurity Testing" | Washington Post, August 6, 2026

Langflow returned to the CISA KEV for the third time in 2026.

CVE-2026-9198 (CVSS 9.8) affects IBM Langflow OSS versions 1.0.0 through 1.10.0. An unauthenticated caller can obtain a superuser token via /api/v1/auto_login and then submit arbitrary code for execution via /api/v1/validate. Fixed in version 1.10.1. Added to KEV August 4 with a federal remediation deadline of August 7. Also added August 4: CVE-2026-34486 (Apache Tomcat, CVSS 7.5), a bypass of the EncryptInterceptor cluster component. For organizations deploying agent frameworks, the pattern now documented across three Langflow KEV entries in a single year is a reasonable basis for treating agent infrastructure as privileged application infrastructure, not experimental developer tooling that sits outside normal vulnerability management.

SOURCE: CISA KEV (CVE-2026-9198 and CVE-2026-34486, added August 4, 2026) | NVD CVE-2026-9198 | IBM security advisory | The Hacker News, August 4, 2026

The One Thing That Matters This Week

Your enterprise did not choose every privileged application running on the phones it manages.

The Samsung research exposed an attack surface that already existed before the enterprise enrolled the device. Samsung Members could launch activity with its own privileges, Samsung Account exposed additional privileged behavior, and Bixby's Capsule infrastructure could execute functions across applications. None of those capabilities came from MDM, the corporate app catalog or an enterprise security policy. They shipped with the device.

Enterprise mobile programs usually have good records of what they deployed themselves. The weaker inventory is what the manufacturer deployed first, which of those applications and services carry elevated privileges, how those components interact, what versions are running and how remediation reaches them. MDM did not create those relationships, and its inventory model was never intended to describe all of them.

Samsung's account and assistant ecosystem gives one concrete example, but every manufacturer brings its own collection of vendor applications, background services and system integrations with elevated access to device functions. Most enterprises already maintain an application inventory. Far fewer maintain an inventory of privileged pre-installed software that records what those components can access, which trust relationships they inherit, whether enterprise tooling exposes those relationships and how quickly vulnerable versions can be identified across the fleet.

An audit that stops at enterprise-installed applications leaves that manufacturer-controlled layer largely unexamined.

My Take

The Bixby research is useful because the attack chain started before the enterprise ever got involved. Samsung Members, Samsung Account and Bixby were already on the device, already trusted, and already wired together through permission relationships Samsung designed. The researchers did not need the enterprise to create that path for them. They figured out how to abuse the one that was already there.

Enterprise mobile security still has a habit of treating the factory-loaded software layer like settled territory. Vet the device model, approve it, enroll it, move on. The Samsung research punches a hole in that assumption. Vendor-loaded applications can carry privileged relationships the enterprise never designed, never approved individually and, in many cases, never modeled at all. A clean corporate app catalog only tells you what your company chose to install. MDM shows you what its management framework was built to expose. Neither magically gives you a map of the trust relationships the manufacturer embedded before the box was opened.

For Samsung fleets, the first job is simple: verify Samsung Members and Samsung Account are on the patched versions. The bigger job is less comfortable. Build an inventory of the vendor-loaded applications that can touch sensitive device functions, record the versions actually deployed, understand how those components are updated, and document whether your existing controls can see the relationships that give them elevated access.

Most mobile programs already have an application inventory. What they usually do not have is an inventory of the software the manufacturer decided to trust on their behalf.

That is where I would start looking.

— William

One Thing Worth Doing This Week

Run a pre-installed application privilege audit on your Samsung fleet.

Start with two checks:

Go one level deeper and pull the application and version inventory for vendor-loaded software across the fleet. Identify which applications can reach sensitive device functions or privileged services, record the versions actually deployed, compare them against the vendor's patched releases, document how those updates reach the device, and check whether your current tooling exposes the permission and service relationships those applications depend on.

Most mobile application inventories were built to answer an enterprise administration question: what software is installed on the device? That is too shallow for this problem. You need to know which vendor-loaded applications arrived with elevated access, what they can reach, whether vulnerable versions are still circulating in the fleet, who is responsible for getting them patched, and where MDM or other mobile controls simply run out of visibility. Once you have that list, you have something a security team can actually audit instead of another spreadsheet proving the phone has apps on it.