InfoSec Briefing - September 20, 2026

🎧 Audio Briefing

Playback Speed:

This is your security briefing for Sunday the 20th of September 2026, covering what the BlueTeamSec community on infosec.pub was sharing over the past day — six stories to get through.

JFrog disclosed a local privilege escalation in Parallels Desktop for Mac — an unprivileged user can inject arguments into the dispatcher service's appliance installer and drop a malicious tar file to get a root shell. One for anyone running the virtualisation software on endpoints.

Hacktron published details on a broader set of vulnerabilities in image processing libraries — specifically libheif and libde265, used to handle HEIF, HEIC, and AVIF files. The flaws affect multiple versions and can lead to memory corruption or remote code execution when untrusted images are processed server-side. Worth flagging if you're running web services that accept image uploads.

Also from Hacktron — a write-up on how researchers compromised multiple OpenAI employee ChatGPT accounts back in July by chaining a heap overflow in the company's Discourse forum with an SSO misconfiguration. What makes this one notable is the use of Claude Opus 5 to automate ARM64 exploit generation, which gave them access to internal GitHub, Slack, and email. We covered a related OpenAI incident on the 14th involving agents and RubyGems — this adds useful context to that earlier story.

Revenue Protect reported the first arrest in Singapore for SMS blaster scamming — a Malaysian man working for loan shark groups sent over ten thousand smishing messages targeting WhatsApp credentials, which were then used for authorised push payment fraud. At least one victim lost eighteen hundred Singapore dollars. Flag this if you're tracking fraud trends in Southeast Asia.

iProov released an experimental draft specification called HAPS — Human Approval and Presence Specification — designed to cryptographically bind human presence and explicit approval to machine-readable actions. It's strictly non-production at this stage, but adds useful context if you're working on high-assurance user confirmation systems or following developments in authentication frameworks.

And finally, Joshua Wright introduced the Dynamic Approach to Incident Response, or DAIR — an iterative framework intended to replace linear models like PICERL and the NIST guidance. The premise is that modern incidents don't stay in neat boxes, so response processes shouldn't either. Worth a read if you're looking at how your team handles persistent threats or incomplete eradication.

That's your briefing for today. All articles are credited to their original authors — the analysis here was automated. We'll be back with the next round soon.

📰 Articles Covered

ParaShells: Parallels Desktop Turns Appliance Install Into a Root Shell - JFrog

This précis covers the security vulnerability identified in Parallels Desktop, as detailed by researchers at JFrog.

### **What Happened**
Researchers discovered a local privilege escalation (LPE) vulnerability, tracked as **CVE-2026-90894**, in Parallels Desktop for Mac. The vulnerability allows an unprivileged local user to exploit a privileged system daemon to execute arbitrary commands with root-level privileges on the host macOS machine.

### **Who Is Affected**
* **Affected Software:** Parallels Desktop for Mac.
* **Vulnerable Versions:** Confirmed in version 26.4.0 (build 57513).
* **Prerequisites:** The attacker must have local access to a Mac machine running the vulnerable Parallels Desktop service. Notably, the attacker does not require administrative privileges or specialized code-signing credentials to carry out the exploit.

### **Technical Details**
The vulnerability stems from the `prl_disp_service` root daemon, which manages various operations and listens on a Unix socket.
1. **Weak Authentication:** The dispatcher socket (`/var/run/prl_disp_service.socket`) is world-writable, and the service authenticates local users based on peer credentials rather than strictly validating their identity or permissions.
2. **Argument Injection:** An attacker can use the `PrlSrv_InstallAppliance` SDK function to supply a malicious `sVmParentPath` argument. By injecting specific characters into this string, the attacker can break out of the intended command structure and manipulate a `tar` command that the root daemon executes.
3. **Command Execution:** By appending the `--use-compress-program=` flag to the command, the attacker forces the root-owned `tar` process to execute a malicious payload of the attacker's choosing as root.

### **Security Implications**
This vulnerability represents a total compromise of the host system. A low-privileged account—potentially compromised through a standard phishing attack, malicious download, or an automated process—can escalate to root. An attacker can leverage this access to:
* Bypass macOS security boundaries.
* Achieve persistence (e.g., by modifying `/etc/sudoers` or installing persistent backdoors).
* Access sensitive data across the entire system.
* Manipulate or disable security software.

### **What Defenders Should Know**
* **Remediation:** The primary defense is to upgrade to **Parallels Desktop 27.0.0** or higher, where this vulnerability has been patched.
* **Detection/Assessment:** Defenders can inspect the permissions of the dispatcher socket. If `/var/run/prl_disp_service.socket` is set to world-writable (mode `0777`), the system is exposed.
* **Host Hygiene:** Given that this attack requires local user access, enforcing strong principles of least privilege and monitoring local user activity remains a crucial layer of defense against initial compromises that could lead to this escalation.
HEIF Heist - Hacktron

"HEIF Heist" is a term coined by Hacktron to describe a class of remote attack vectors targeting services that process untrusted HEIF, HEIC, or AVIF image files 【1】. By exploiting vulnerabilities in the underlying native image-decoding libraries, attackers can bypass application-level security controls to trigger memory corruption, arbitrary heap data exposure, or remote code execution (RCE) 【1】.

### Technical Details
The vulnerability resides within native C/C++ parsers—specifically `libheif` and `libde265`—that are frequently used for decoding these high-efficiency image formats 【1】. These libraries are often introduced to production environments indirectly, bundled within common wrappers such as ImageMagick, libvips, or Sharp, as well as in standard distribution packages and container base images 【1】.

Because the flaw is located at the native library level, it is language- and framework-agnostic, affecting any backend that processes untrusted image uploads 【1】. Even in scenarios where RCE is not successfully achieved, an attacker may still perform arbitrary heap disclosure, allowing them to steal sensitive in-memory data, such as environment variables or other users' information 【1】.

### Who is Affected
The issue impacts a wide ecosystem of services and is not limited to a single version or release family; it spans multiple versions (e.g., 1.19.x through 1.23.x) 【1】. Any service that decodes HEIF/AVIF files and has not applied the latest upstream patches is considered potentially vulnerable 【1】. Specific platforms, such as Discourse and Next.js, have also issued their own security advisories regarding this threat 【1】.

### Guidance for Defenders
- **Patch Dependencies:** Immediately update `libheif` to version `v1.23.2` or later and ensure `libde265` is updated to the latest available version via distribution channels or direct builds 【1】.
- **Platform Updates:** If you self-host software platforms like Discourse or use frameworks like Next.js, verify that you are running the latest releases and follow their specific security guidance 【1】.
- **Minimize Attack Surface:** If HEIF/AVIF processing is not a business requirement, disable the capability entirely 【1】.
- **Implement Isolation:** For pipelines that must process these image formats, utilize defense-in-depth strategies such as running the decoding process within hardened, ephemeral sandboxes to limit the impact of potential future memory-safety vulnerabilities 【1】.
Hacking OpenAI - Hacktron

This precis outlines the details of the security research published regarding vulnerabilities at OpenAI.

### What Happened
On July 25, 2026, researchers successfully compromised multiple OpenAI employees' ChatGPT accounts by chaining two critical vulnerabilities 【1】. A primary vector was OpenAI's community help forum, which allowed for account takeovers until approximately July 2026 【1】. The researchers demonstrated that this forum compromise could be escalated into full access to internal OpenAI resources, including repositories and connected services 【1】.

### Who is Affected
* **OpenAI:** Employees were directly affected through account takeovers.
* **Discourse Users/Admins:** Organizations using self-hosted Discourse forums were vulnerable to code execution if they were running older Docker images containing a vulnerable `libheif` dependency 【1】.
* **OpenAI SSO Users:** Any first-party or third-party service utilizing OpenAI’s Single Sign-On (SSO) configuration was potentially exposed to similar escalation risks, as the vulnerability was rooted in how SSO handled the session compromise 【1】.

### Security Implications
The research highlights a significant shift in the threat landscape: AI-driven exploit generation. The researchers utilized advanced AI models (specifically citing "Claude Opus 5") to automate the creation of a complex ARM64 exploit within hours, which a previous model version had struggled to produce 【1】. This effectively lowers the barrier for attackers by turning scarce, expert-level human effort into automated compute-intensive tasks 【1】.

### Technical Details
* **Initial Entry:** The exploit relied on a heap buffer overflow in `libheif` during HEIC image decoding, which led to Out-of-Bounds (OOB) R/W primitives 【1】.
* **Escalation:** The researchers combined the `libheif` exploit with an OpenAI-specific SSO issue. Once the forum account was compromised, the SSO flaw allowed the attackers to pivot from the forum into sensitive services like GitHub, Slack, and email accounts linked to the employees' credentials 【1】.

### What Defenders Should Know
* **Patching:** Self-hosted Discourse users must rebuild their installations using the latest Docker images. Simply running a web-interface update is insufficient because it does not replace the underlying, potentially vulnerable, system-level images 【1】.
* **Package Management:** Ensure `libheif` and `libde265` are updated to the latest security-patched versions (e.g., `libheif` v1.23.4 as of September 14, 2026) 【1】.
* **Defense in Depth:**
* Disable untrusted image decoding (HEIF/AVIF) in production architectures unless absolutely necessary 【1】.
* Isolate image-processing pipelines within hardened, ephemeral sandboxes 【1】.
* Utilize security policies (such as those in ImageMagick) to restrict allowed file formats and limit resource usage 【1】.
First SMS Blaster Scammer Arrested in Singapore Was Targeting WhatsApp Users - Revenue Protect Limited

The arrest of Ong Kak Seng, a 28-year-old Malaysian man, marks a significant development in the battle against mobile-based fraud in Singapore. Below is a detailed precis of the incident.

### What Happened
Ong Kak Seng was recruited by a loan shark to operate a mobile SMS blaster (a "fake cell tower" device) across Singapore. Driven by financial desperation to pay off personal debt, Ong assembled the equipment—provided by a go-between—and spent over a month (October 13 to November 18, 2025) driving through high-density areas of Singapore for 10–12 hours a day. He coordinated his activities via a Telegram group with his handlers, who were reportedly linked to Chinese criminal syndicates. He was ultimately apprehended during a nationwide police operation aimed at tracing the source of malicious messages 【1】.

### Who Was Affected
The activity had a widespread reach, impacting the mobile signals of thousands of unsuspecting individuals:
* **Exposure:** Approximately 31,820 mobile phones fell within the range of the SMS blaster during its operation 【1】.
* **Victimization:** Over 10,500 smishing messages were successfully transmitted. At least one victim was confirmed to have been defrauded of SGD 1,800 (approx. USD 1,400) via a bank transfer 【1】.

### Security Implications
This case highlights a strategic shift in how criminals bypass robust national anti-scam measures. Instead of attempting to compromise telecom infrastructure directly or rely on traditional bulk SMS gateways—which are heavily monitored—syndicates are utilizing mobile "blasters" to gain a foothold in messaging platforms:
* **Account Hijacking:** The primary goal was to phish WhatsApp credentials. By taking control of a victim's account, criminals can then facilitate authorized push payment fraud from a trusted source 【1】.
* **Gateway Strategy:** Criminals are increasingly using basic telecom services as a low-tech bridge to exploit high-security communication apps 【1】.

### Technical Details
* **Equipment:** The system consisted of mobile components and battery packs, which were assembled on-site. The operator used two mobile phones—purchased locally in Geylang—along with a specific software application to control the blaster's transmissions 【1】.
* **Operation:** The blaster was designed to function as an unauthorized base station, allowing it to push messages to all devices in its immediate vicinity 【1】.

### What Defenders Should Know
* **Cross-Border Patterns:** SMS blaster usage is a known issue in the region, particularly near transport hubs between Singapore and Malaysia. Defenders should be aware that these methods are highly portable across international borders 【1】.
* **Diversification of Scams:** While this case focused on smishing, SMS blasters have a documented history of being used to advertise illegal gambling services, and defense strategies should account for these various threat vectors 【1】.
* **Information Silos:** Criminal syndicates share tactics across borders more effectively than anti-fraud professionals do. Security teams are encouraged to look beyond local or language-specific peer groups to understand the global threat landscape regarding SMS blaster deployment 【1】.
HAPS: Human Approval and Presence Specification (HAPS) — experimental draft specification, schemas, test vectors and formal models. Not production-ready. - iProov

The Human Approval and Presence Specification (HAPS) is not an incident report or an exploit, but rather an **experimental, open-source protocol proposal** designed to address the challenge of binding human presence and explicit approval to specific, machine-readable actions.

Below is a detailed precis of the HAPS framework based on the provided documentation:

### What is HAPS?
HAPS is a proposed "composition layer" intended to provide relying parties with cryptographic assurance that a human has freshly approved a specific action. It serves as a bridge between authentication systems (like OAuth, OIDC, or WebAuthn) and the actual execution of sensitive commands, ensuring that the "what" being approved by a user is cryptographically bound to the "what" being executed by a machine.

### Who is Affected (Target Audience)
The protocol is intended for:
* **Developers and architects** building secure systems that require high-assurance user confirmation for critical operations (e.g., high-value financial transactions, administrative privilege escalation).
* **Identity providers** seeking a standardized way to signal human presence and intent.

### Technical Details
HAPS functions by generating a "Consent Credential," a signed data structure that includes:
* **Canonicalized Action Data**: Uses RFC 8785 (JCS) and SHA-256 to hash the `intent_hash` (the action) and the `presentation_hash` (what the user actually saw).
* **Contextual Constraints**: Includes `aud` (audience), `challengeId` (replay protection), `exp` (expiration), and `jti` (unique identifier) to ensure freshness and prevent replay attacks.
* **Assurance Levels**: Communicates the quality of the signal, distinguishing between "agent-resistant" factors (hardware-backed biometrics) and "agent-accessible" factors (OTP or push notifications).
* **Verification**: The repository provides test vectors, JSON schemas, and a Tamarin symbolic model for formal security analysis.

### Security Implications
* **Composition, Not Replacement**: HAPS does not replace existing authentication protocols; it is a specialized layer meant to sit on top of them. It does not independently confer authorization or prove the legitimacy of the underlying user identity.
* **Experimental Risk**: The protocol is strictly **non-production-ready**. Success in passing provided tests does not equate to secure implementation or full protocol conformance.
* **Operational Trust**: The protocol's effectiveness is entirely dependent on the integrity of the provider, the correctness of the implementation, and the robustness of the verifier’s policy regarding replay protection and state consumption.

### What Defenders Should Know
* **Threat Modeling**: Defenders must distinguish between *agent-resistant* and *agent-accessible* factors. An agent-accessible factor (like an SMS OTP) can be intercepted by automated software, whereas an agent-resistant factor (like a FIDO2 passkey) requires human physical presence.
* **Conformance**: Implementations should be measured against the specification (`conformance-v0.4.md`) and the project's official test vectors.
* **Intellectual Property**: While the specification is open-sourced under the Apache License 2.0, this does not grant rights to iProov’s proprietary technologies, branding, or services.
* **Vulnerability Reporting**: The project emphasizes that security vulnerabilities should be reported privately in accordance with the repository's `SECURITY.md`.
Dynamic Incident Response: A Framework for Security Teams - Joshua Wright

The provided text indicates that the website **dynamicincidentresponse.com** is not a report on a specific security incident (such as a breach or vulnerability disclosure), but rather the landing page for a book and professional framework titled **"Dynamic Incident Response"** by Joshua Wright.

Accordingly, the "what happened" is the introduction of a new incident response methodology rather than a cyberattack. Below is a precis based on the content of the framework.

### What is the Dynamic Incident Response (DAIR) Framework?
DAIR (Dynamic Approach to Incident Response) is an iterative framework designed to replace traditional, linear incident response (IR) models like PICERL or NIST SP 800-61 【1】.

The author argues that traditional, sequential models are often insufficient for modern threats because they fail to account for the reality that incident scope changes, attackers return after containment, and eradication efforts often miss persistent mechanisms 【1】.

### Who is affected / Target Audience
This framework is intended for **security teams and incident responders** working in complex environments where incidents involve active attackers and shifting priorities. It is designed to be a practical guide for teams that find rigid, checklist-based IR processes to be ineffective during evolving, real-world threats 【1】.

### Technical Details & Framework Structure
DAIR is built on Boyd’s OODA loop (Observe, Orient, Decide, Act) and introduces a non-linear process organized around five waypoints and a repeating loop 【1】:

* **Five Waypoints:** Prepare, Detect, Verify and Triage, Response Actions, and Debrief 【1】.
* **The Response Actions Loop:** A cycle consisting of **Scope, Contain, Eradicate, and Recover** 【1】.

Unlike traditional models, DAIR treats **Verification, Triage, and Scoping** as explicit, ongoing waypoints rather than one-time initial steps, allowing the team to re-enter the response loop whenever new evidence emerges 【1】.

### Security Implications & What Defenders Should Know
* **Adaptability:** Defenders should recognize that treating IR as a fixed, linear checklist can lead to premature or incomplete responses—such as underestimating the scope of a breach or failing to identify persistence mechanisms 【1】.
* **Iterative Process:** The core takeaway for defenders is that incident response must be treated as an iterative process that adapts to the specific, changing conditions of the incident rather than a rigid sequence to follow in order 【1】.
* **Integration:** The framework includes a crosswalk to the NIST Cybersecurity Framework (CSF) 2.0, allowing teams to align the DAIR model with existing organizational standards 【1】.