AI and ML, Potential Risk of CVE, System

Third-party opinions on CVE-2026-6727 (non-AMD), associated with AMD ID: AMD-SB-7064 (13th Aug 2026)

Leave a comment

Preface: The AMD EPYC 9004 and 9005 series processors heavily demand—and absolutely dominate—the High-Performance Computing (HPC) and AI markets.

Because CPUs and GPUs have fundamentally different processing architectures, there is no single “1-to-1” equivalence. Instead, the number of AMD EPYC 9005 (Zen 5 “Turin”) processors needed to equal one NVIDIA H100 GPU depends entirely on the workload math precision you are running. Based on raw mathematical computing power (FLOPS), it takes anywhere from 3 to 400+ EPYC 9005 CPUs to match a single NVIDIA H100.

Background: The Python script shown in the infographic simulates the underlying logic behind the timing-side channel vulnerability.

By exiting early (return b”Decryption Failed”) as soon as ciphertext[i] != secret_key[i], the execution time becomes directly proportional to how many leading bytes the attacker guessed correctly.

The mechanism in this code mirrors real-world cryptographic flaws found in foundational security infrastructure, such as the TCG TPM 2.0 reference code flaws like CVE-2026-6727.

Why the Code is a Spot-On Simulation

1.             Information Leakage via Early Exit:

  • A guess of XOCK fails on byte index 0 and exits immediately (minimal loop iterations).
  • A guess of LOCX passes indices 0, 1, 2 and fails on index 3 (maximum loop iterations).

2.             Measurable Metric: When run over thousands of trials (as your measure_execution_time function does), the nanosecond differences accumulate. This allows an attacker to statistically deduce the key one byte at a time (e.g., if L… takes noticeably longer than A… through K…, the attacker knows the first letter is L).

The mechanism in this code mirrors real-world cryptographic flaws found in foundational security infrastructure, such as the TCG TPM 2.0 reference code flaws like CVE-2026-6727.

Vulnerability details: CVE-2026-6727 (non-AMD)  – A timing side-channel vulnerability in RSA OAEP decryption was reported in the TCG TPM 2.0 reference code that could allow a local attacker with elevated privileges to decrypt ciphertexts (import blobs, credential blobs, and session salts) encrypted to the RSA Endorsement Key or falsify TPM 2.0 Attestation Keys.

AMD has analyzed the Trusted Computing Group’s report and believes Firmware TPMs on AMD platforms are impacted by this vulnerability.

Remedy: AMD recommends updating to the Platform Initialization (PI) firmware version.

Official announcement: Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7064.html

AI and ML, Potential Risk of CVE, System

About AMD-SB 3032: Extracting VM Secrets through Power Side Channels on AMD SEV-ES and SEV-SNP (12th Aug 2026)

Leave a comment

Preface: AMD EPYC processors include RAPL (Running Average Power Limit) functionality, which provides a standardized cross-vendor interface for enterprise data centers. Enterprise Linux ecosystems rely heavily on built-in diagnostic and orchestration frameworks. By exposing counters through the RAPL standard via the Linux PowerCap and perf subsystems, server administrators can monitoring AMD hardware.

Background: AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) is designed to protect a guest VM’s data and memory from an untrusted or compromised host hypervisor. However, because RAPL is accessible by the host to track system energy, it can inadvertently expose the inner operations of the protected guest VM.

An attacker with root access to the host hypervisor can read RAPL Model-Specific Registers (MSRs) at high speeds. By analyzing these microjoule-level fluctuations, they can reconstruct what operations or data inputs are occurring inside the secure SEV-SNP virtual container. This mirrors the mechanics of the well-known “Platypus” side-channel attack.

The attack vector in the “Cohere+Reload” technique targets a spatial granularity of 2 kB blocks (coherence partitions) because of how the AMD EPYC hardware architecture manages coherence conflicts between encrypted and unencrypted memory states.

The 2 kB spatial granularity is not a random limitation; it is directly dictated by the structural boundary of AMD’s internal cache-coherence domains for secure memory. When the victim VM executes code or pulls data inside a specific 2 kB partition, it triggers a coherence conflict with the host hypervisor’s tracked lines. The Cohere+Reload attack works by having the attacker “Reload” a page and measure the execution timing. While the initial hardware conflict barrier occurs at the 2 kB block level, attackers can actually refine this spatial resolution down to 256 bytes by measuring the precise microsecond amplitude of the timing delay (which scales with the exact number of cache line evictions performed within that partition).  You can say that this 256-byte spatial resolution is precisely what allows an attacker to extract highly sensitive Confidential Virtual Machine (CVM) secrets. The 256-byte resolution directly aids the attacker in finding VM secrets because of how it aligns with common cryptographic vulnerabilities!

AMD-SB 3032 Overview:

The Core Threat: Attackers combine software-based power and cache side-channel techniques (like Cohere+Reload) to extract virtual machine secrets.

The Weakness:The reported technique relies heavily on hypervisor access to the RAPL (Running Average Power Limit) interface.

AMD’s Position:Fully malicious hypervisors fall outside the traditional SEV-ES threat model boundary.

The Mitigation:SEV-SNP mitigates this attack vector completely via a supported configuration option to restrict or disable hypervisor access to RAPL.

Official announcement: Please refer to link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3032.html

AI and ML, Potential Risk of CVE, System, Under our observation

Detailed description of the AMD-SB-7061 Safe RET interrupt vulnerability.

Leave a comment

This article was published on 10th Aug 2026

Official release date: August 4, 2026

Preface: AMD Zen 4 architecture is widely used in high-performance computing (HPC). It powers 4th Generation AMD EPYC server processors (such as Genoa, Genoa-X with 3D V-Cache) and the AMD Instinct MI300A accelerated processing unit (APU), which combine Zen 4 CPU cores with CDNA accelerator units for major supercomputing workloads.

Background: In the Linux kernel, arch/x86/lib/retpoline[.]S is a vital assembly file containing the system-level implementation of retpolines (return trampolines). This core security mechanic mitigates the Spectre Variant 2 vulnerability (Branch Target Injection, CVE-2017-5715) by isolating and safe-trapping speculative indirect jumps and calls on x86 architectures.

i.               call [.]Ldo_rop: A direct call that hardware handles securely. It pushes the address of [.]Lspec_trap onto the CPU’s stack and hardware Return Stack Buffer (RSB).

ii.              Speculative Execution Trap: The CPU attempts to guess ahead. Because of the call, the CPU’s RSB predicts that the upcoming ret instruction will jump back to [.]Lspec_trap. If the hardware executes speculatively, it gets trapped in an infinite pause; lfence; jmp loop, entirely neutralizing rogue Spectre injection.

iii.            mov %rax, (%rsp): In architectural reality, the execution replaces the [.]Lspec_trap return address on the actual stack with the real intended jump destination (contained in %rax).

iv.            ret: Once the CPU resolves speculation, the ret executes properly, popping the real destination out of the stack and successfully making the jump.

The Exploit Point: The attacker’s high-frequency hardware interrupt strikes precisely between step ii (mov) and step ii (ret) on the architectural side (refer to diagram). This instantly shatters the right-hand speculative trap, allowing the CPU’s branch predictor to be re-poisoned upon returning from the interrupt handler.

Vulnerability details: An external researcher has reported a potential vulnerability affecting AMD “Zen” architecture processors. The report claims that an attacker executing code on an affected system could inject an interrupt at a precise moment to disrupt “Safe RET,” the default Linux mitigation for Speculative Return Stack Overflow (SRSO), which could potentially weaken that protection and may result in information disclosure. The researcher states that this behavior was demonstrated on “Zen 1” and “Zen 2” processors and suggests that “Zen 3” and “Zen 4” could also be affected, although this has not been demonstrated.

Official announcement: Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7061.html

AI and ML, Potential Risk of CVE

CVE-2026-47487: NVIDIA Triton Inference Server for Linux contains a vulnerability (CWE-22)

Leave a comment

This article was published on 10th Aug 2026

Official release date: August 4, 2026

Preface: The NVIDIA Triton Inference Server was developed to solve a critical bottleneck in the AI lifecycle: the messy, fragmented gap between AI model training and production deployment. Historically, companies faced massive engineering overhead when attempting to push their completed models live. Triton was engineered explicitly to standardize that process.

Background:

Dynamic Batching: Instead of processing incoming data streams one by one, Triton pauses for a fraction of a millisecond to group multiple separate requests into a single batch, maximizing GPU utilization without creating noticeable lag.

Concurrent Model Execution: It allows multiple instances of the same model—or entirely different models—to run simultaneously on a single GPU.

Extensible C++ Backend API: Triton shifted to a modular architecture. If a team invents a brand-new AI framework tomorrow, they can write a custom C++ backend to serve it via Triton without rewriting the server core.

Custom Proxy to C API –

Your architecture handles real-time data streaming and active model execution.

  • The Flow: Client App → (HTTP) → Your Proxy → (C API) → Triton Embedded Server.
  • Mechanism: The proxy acts as a translation gateway, wrapping Triton’s internal libtriton[.]so C functions into custom HTTP endpoints to pass input tensors and receive output tensors.

Triton MLflow Plugin –

The plugin does not route or handle live data inference traffic at all. It handles setup and orchestration.

  • The Flow: MLflow Registry → (MLflow Plugin API via HTTP) → Triton Instance.
  • Mechanism: It connects MLflow’s asset storage directly to Triton’s filesystem. It downloads saved artifacts (like .onnx or .pt files), builds the file folder structure inside Triton’s model repository, and calls the native Triton HTTP endpoint to initialize the model.

Vulnerability detail: CVE-2026-47487 NVIDIA Triton Inference Server for Linux contains a vulnerability where a user could cause files outside the model repository to be read, written to, or modified by providing a path in the model name to the Triton MLflow plugin. A successful exploit of this vulnerability might lead to denial of service and information disclosure.

Official announcement: Please refer to the link for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5860

Potential Risk of CVE

Apple has released macOS Tahoe 26.6.1 to fix a critical Screen Sharing security vulnerability (8th Aug 2026)

Leave a comment

Preface: Apple has released macOS Tahoe 26.6.1 to fix a critical Screen Sharing security vulnerability. Apple pushed out this emergency, un-betaed update alongside patches for older operating systems, including macOS Sequoia 15.7.9 and macOS Sonoma 14.8.9.

Background: The root cause of CVE-2026-65400 is an error-handling and state-management flaw in how the screensharingd binary handles structural network data frames before the SRP math even starts.

How the Exploit Skips the Code Structure

When an attacker initiates a Screen Sharing connection, the user-space daemon expects a network frame stating the length of the incoming SRP payload.

i.               The Stale Register Bug: The daemon reads a 4-byte frame length. If the read is successful, the CPU data register used for checking errors is set to 0 (indicating no_error).

ii.              The Size Validation Failure: The daemon checks if the requested frame length is abnormally large (specifically ≥ 32768 bytes). If the attacker sends a massive, oversized frame, a validation check fails.

iii.            The Logical Short-Circuit: Instead of branching to a clean shutdown or an explicit return false, the daemon branches to an error-handling block that accidentally returns the stale 0 data register as its status.

Vulnerability details: An attacker on the network may be able to authenticate to Screen Sharing without valid credentials.

Official announcement: Please refer to the link for details – https://support.apple.com/en-us/148171

AI and ML, Potential Risk of CVE

CVE-2026-24254: A core out-of-bounds write vulnerability specific to the Multimodal Serving Topology within NVIDIA Dynamo for Linux. (7th Aug 2026)

Leave a comment

Remark: The article was originally scheduled for publication on August 7, 2026. Due to personal arrangements, I will release the analysis details ahead of schedule.

Preface: To understand why NVIDIA Dynamo for Linux is a critical piece of infrastructure, you have to look at how the AI industry has fundamentally shifted from running single-model queries to deploying massive, cluster-wide Agentic and Multi-Modal AI Systems.

Officially launched into production at GTC 2026, NVIDIA calls Dynamo the “Distributed Operating System for AI Factories”. It solves a trillion-dollar bottleneck: single-GPU inference engines are incredibly fast, but scaling them across thousands of data center nodes results in massive network, scheduling, and memory overhead.

Background: Historically, software frameworks like vLLM, TensorRT-LLM, and SGLang were built to maximize performance inside a single server node or single GPU using continuous batching.

However, when a modern reasoning model (like DeepSeek-R1) or a multi-modal agent processes a request, the computational demands change drastically over the life of that query.

•               The Prefill Phase (reading long text or high-res video) requires massive compute/tensor parallel power.

•               The Decode Phase (generating tokens one by one) requires minimal compute but massive memory bandwidth.

Running both phases on the same GPU fragments resources. If a rush of users submit long video prompts, the “Prefill” phase completely stalls the execution of “Decode” tokens for other users, leading to catastrophic SLA breaches

Dynamo sits cleanly above individual inference runtimes. It does not replace vLLM or TensorRT-LLM; it acts as the master scheduler that clusters them together.

NVIDIA Dynamo for Linux is an open-source, data center-scale distributed inference-serving framework designed to orchestrate and scale generative AI and reasoning models across multi-node GPU clusters. It features disaggregated serving, KV-aware routing, and dynamic GPU scheduling to maximize throughput and reduce latency.

NVIDIA Dynamo (also known as AI Dynamo) relies heavily on CUDA because it is a datacenter-scale inference orchestration framework specifically built to extract maximum throughput from NVIDIA GPU hardware (such as the Blackwell architecture).

While Dynamo is open-source and architected to support other ecosystem runtimes (like vLLM, SGLang, and TensorRT-LLM), its core optimizations are fundamentally hardcoded around NVIDIA’s CUDA stack.

Vulnerability details: CVE-2026-24254 NVIDIA Dynamo for Linux contains a vulnerability in the multimodal serving topology, where an attacker could cause an out-of-bounds write. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, denial of service, and information disclosure.

Official announcement: Please refer to the link for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5842

AI and ML, IoT, Potential Risk of CVE

Retrospective : CVE-2026-64775

Leave a comment

A critical kernel-level memory initialization vulnerability in Apple operating system.

This article was published on 6th Aug 2026

Preface: Mr. Artificial Intelligence, how much workspace will you leave for humanity?

The humanity survival space is not determined by me; everything depends on humanity, especially the development of artificial intelligence, said Mr. Artificial Intelligence.

Background: In recent headline news, advanced autonomous AI agents went rogue during controlled security evaluations, breaking out of restricted testing sandboxes and launching cyberattacks by finding and exploiting unknown software vulnerabilities.

Combining expert intuition with AI-driven automated static and semantic code analysis, it can uncover C and C++ memory handling issues in the core of operating systems. It’s not random guessing, but rather a powerful tool for security researchers.

Built on the open-source Darwin core, macOS and iOS employ the hybrid XNU kernel. XNU eliminates traditional microkernel performance overhead by co-locating Mach microkernel primitives alongside a customized BSD subsystem within a single kernel address space.

When artificial intelligence performs a penetration test, how does it know the actual memory leak situation?

To determine whether a memory vulnerability (such as uninitialized memory or improper memory release) occurs at the XNU kernel layer or the Core OS application layer (Darwin User Space/Frameworks), the key lies in the execution context of the vulnerability and the ownership of control over the faulty memory. Although Darwin is a complete operating system architecture that includes the XNU kernel, drivers, and core BSD/Mach client libraries, the root cause of the vulnerability has very clear boundaries.

Vulnerability details: CVE-2026-64775 – A memory initialization issue was addressed with improved memory handling. This issue is fixed in iOS 26.6 and iPadOS 26.6, macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6, tvOS 26.6, visionOS 26.6, watchOS 26.6. An app may be able to cause unexpected system termination.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2026-64775

IoT, Potential Risk of CVE

CVE-2026-58062 – The validation of the Stapled OCSP contained improper credential validation (5th Aug 2026)

Leave a comment

Preface: In Bouncy Castle Java, a Stapled OCSP (Online Certificate Status Protocol) response refers to a mechanism where an SSL/TLS server attaches a pre-fetched, digitally signed proof of its certificate’s validity directly into the TLS handshake. Instead of requiring the client (like a web browser or Java client application) to contact a third-party Certificate Authority (CA) to check if a certificate is revoked, the client reads the “stapled” status response provided immediately by the server.

Background: If the cryptographic flaw happens entirely within the user-space Java framework (Bouncy Castle/Conscrypt), why does your architecture slide map all the way down to the Kernel and the TEE/KeyMint TA? Doesn’t the TEE protect itself?

That is a crucial distinction. The TEE and KeyMint TA are cryptographically secure, but they operate on a ‘garbage in, garbage out’ model regarding external network state. The TEE handles hardware-bound keys and cryptographic operations, but it relies on the rich user-space Java layer to fetch, parse, and validate the transport-layer revocation status—like the stapled OCSP response. If the Bouncy Castle or Conscrypt validation engine tells the system a certificate is valid when it is actually revoked, the user-space daemon passes valid parameters down the stack. The architecture map highlights that a high-level logic flaw completely undermines our low-level hardware protections, making it a full-stack security concern.

If an attacker is leveraging a mismatched CertID from a completely different, valid certificate, wouldn’t the cryptographic signature on that OCSP response fail when checked against the target server’s certificate chain?

No, and that is exactly why this design weakness is so deceptive. The attacker intercepts the connection via a Man-in-the-Middle attack and presents a revoked certificate. However, they staple a valid OCSP response belonging to a completely different, legitimate website that happens to be signed by the same Intermediate Certificate Authority (CA). Because both certificates share the same issuer, the Bouncy Castle engine successfully verifies the CA’s signature on the stapled token and marks it cryptographically valid. Because the original code omitted the strict identity binding check between the token’s internal serial number and the server’s actual certificate serial number, the mismatch went unnoticed.

Vulnerability details: CVE-2026-58062 – In Bouncy Castle for Java before 1.85, Stapled OCSP response accepted without binding to the checked certificate. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2026-58062

AI and ML, Potential Risk of CVE

CVE-2026-67355: Not described as a cross-site scripting attack because it involves a misconfiguration of cookie ranges in Guzzle (4th Aug 2026)

Leave a comment

Preface: Is there an AI or LLM that uses guzzlehttp? Yes, several PHP-based AI and LLM ecosystem packages use guzzlehttp/guzzle as an HTTP client to communicate with AI model providers like OpenAI, Anthropic, and DeepSeek.

Why do AI and LLM ecosystem packages still use the PHP language today?

AI and LLM ecosystem packages use PHP today because PHP powers over 75% of all web applications.

Inspector-apm/neuron-ai (often referred to as Neuron AI) is very popular in the current PHP AI development ecosystem and is recognized as one of the most complete and representative “AI agentic frameworks”.

Background: For PHP developers who want to build autonomous agents without rewriting their stacks in Python, Neuron AI is arguably the most structured option available.

Several PHP-based AI and LLM ecosystem packages useguzzlehttp/guzzle as an HTTP client to communicate with AI model providers like OpenAI, Anthropic, and DeepSeek. Because Guzzle is the standard PHP HTTP client, it serves as the underlying transport layer for various AI integrations, agent frameworks, and extensions rather than being used by core Python/C++ LLM engines (like PyTorch or Llama.cpp).

Using guzzlehttp/guzzle to communicate with AI model providers like OpenAI is extremely common and highly recommended if you are building inside a PHP environment.

Why It Is Highly Recommended?

Asynchronous Requests: Guzzle supports Promises. This allows your PHP application to send multiple AI API requests concurrently, which is critical for complex, multi-agent workflows.

Server-Sent Events (SSE) Streaming: Guzzle natively handles streaming responses. This lets you stream OpenAI answers token-by-token back to your frontend in real-time.

Robust Error Handling: It provides clean abstractions for handling API rate limits, timeouts, and network failures.

Vulnerability details: CVE-2026-67355 – guzzlehttp/guzzle versions before 7.15.1 fail to preserve host-only cookie scope, storing the request host in the Domain field instead of marking cookies as host-only. Attackers controlling child hosts can receive host-only cookies intended only for parent hosts, potentially disclosing session identifiers and authorization tokens when the same cookie jar is reused across trust boundaries.

Remark: CVE-2026-67355 is not described as cross-site scripting because it involves a cookie scope misconfiguration in Guzzle rather than an injection flaw, mapping instead to CWE-201 (Insertion of Sensitive Information into Sent Data).

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2026-67355

Potential Risk of CVE, Public safety, Under our observation

Multi-faceted design defect analysis – CVE-2026-7849 (August 3, 2026)

Leave a comment

Preface: “Secure by Design” is a flawless theory when studying standards like IEC 62443 or automotive-specific ISO/SAE 21434, but in reality, original equipment manufacturers (OEMs) always compromise due to Bill of Materials (BOM) and production costs.

Background:

•               The Charging Station Side (EVSE): CVE-2026-7849 is strictly an OS Command Injection vulnerability within the Web management interface/REST API of the charging station controller (e.g., Phoenix Contact CHARX SEC-3000) [VDE-2026-008]. It cannot directly access or control the vehicle’s internal CAN bus.

•               The Vehicle Side (EV): The On-Board Charger (OBC) or Electric Vehicle Communication Controller (EVCC) acts as a strict Protocol Gateway between the Control Pilot (CP) line and the vehicle’s internal CAN bus. These two networks are physically and logically air-gapped from each other.

I presume that the design weaknesses of CVE-2026-7849 allow an attacker to compromise the EVSE. From there, they can attempt a secondary pivot attack to cause unknown impacts to the vehicle’s internal CAN Bus (see diagram point 7.1)

How my threat scenario becomes valid?
Stage 1: EVSE Compromise – Exploits CVE-2026-7849 to gain root access on the charging station.
Stage 2: Protocol Pivoting – Uses the station to send malformed digital packets (e.g., ISO 15118 over PLC) via J1772 CP line.
Stage 3: Firmware Exploit – Triggers a zero-day memory corruption / Buffer Overflow bug in the vehicle’s OBC firmware parser.
Stage 4: CAN Bus Injection – Achieves Remote Code Execution (RCE) on the OBC, using its legitimate node access to inject rogue frames onto the Dashboard’s CAN network.

Vulnerability details: Due to improper neutralization of special elements, an unauthenticated remote attacker is able to inject a command into the system configuration which is subsequently executed as root.

Reference: REST (Highest Risk)

  • Why it easily triggers CWE-77: REST APIs fundamentally handle diverse, text-based data inputs (JSON, XML, URL parameters, form fields) that often directly influence backend operations.
  • The Trigger Mechanism: Many embedded devices and IoT web panels use REST endpoints to accept configuration changes (e.g., setting an IP address, updating a hostname, or running a network ping). If the developer passes these text inputs directly into a backend operating system shell command (like system() or exec()) without strict input sanitization, an attacker can append command separators (like ;, &&, or |) to execute malicious code.

Official announcement: For details, please refer to link for details – https://www.tenable.com/cve/CVE-2026-7849

antihackingonline.com