Category Archives: Under our observation

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

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

AI and ML, Under our observation

A more imaginative assumption on TDXRay: Microarchitectural Side-Channel Analysis of Intel TDX for Real-World Workloads (15th MAY 2026)

Leave a comment

Preface: In these scenarios (see attached diagram), microarchitecture side-channel attacks targeting Intel TDX can directly impact and jeopardize the security of AMD accelerators.

Even though the AMD Instinct APU operates on a completely different silicon package, the two architectures are fundamentally tied together by a shared software stack, device driver interface, and physical interconnect fabric.

The specific risks regarding how TDXRay and cross-domain side-channel leakage bypass the hardware boundary in your diagram are detailed below:

Technical details:

1. Host-Side Driver Leakage (The Primary Target)

As illustrated in attached diagram, the ROCm Driver and HIP Runtime execute inside the Intel TDX Virtual Machine / Trust Domain.

•When primitives like those found in the TDXRay research paper (e.g., page-level or cache-line tracking) are utilized by an untrusted host hypervisor, they target the Intel CPU’s caches and memory controller.

•Because the Intel CPU must actively prepare, schedule, and feed data arrays (h_a, h_b) to the AMD accelerator, the memory access patterns of the ROCm driver itself are leaked.

•An attacker can infer exactly when the AMD kernel is being launched, what memory addresses are being mapped, and the size or stride of the datasets being transferred.

2. Interconnect Fabric Bottlenecks & Shared Cache Timing

The highlighted section in your diagram notes that memcpy can leak info via cache and memory controller interaction.

•During hipMemcpyHostToDevice or hipMemcpyDeviceToHost, data travels across the PCIe Gen 5 / CXL Interconnect Fabric.

•If a malicious actor on the host hypervisor induces resource contention on the shared Intel CPU core or memory bus, they can observe subtle latency shifts.

•By monitoring the timing delays of the Intel CPU waiting for the AMD APU to complete its tasks (hipDeviceSynchronize), the attacker can infer secret-dependent execution paths inside the AMD hardware without ever probing the AMD chip directly.

3. The Cross-Domain Threat Model (AMD SEV-SNP Parallel)

According to AMD’s Official Security Bulletin (AMD-SB-3044) published regarding the TDXRay findings, these types of microarchitectural host-side tracing methodologies fall within a category of behaviors that affect both Intel TDX and AMD SEV-SNP.

If an application leaks data structure layouts through its memory access patterns on the Intel host, the fact that the actual matrix operations happen on an AMD chip does not protect the workflow’s overall confidentiality.

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

Under our observation, Virus & Malware

Checkmarx Jenkins AST Plugin Compromised (14th May 2026)

Leave a comment

Preface: Jenkins’ popularity and its rich plugin ecosystem are the main reasons for integrating event monitoring tools with it. While there isn’t a single “API plugin,” Jenkins has a powerful built-in remote access API (supporting XML, JSON, and Python), which many external monitoring tools use to retrieve data.

Background: With its unparalleled flexibility, vast plugin ecosystem, and vendor neutrality, Jenkins remains the preferred tool for cloud applications, especially in DevOps environments. Despite the emergence of many newer cloud-native tools, Jenkins remains the preferred solution for complex, hybrid, or highly customized CI/CD pipelines.

The TanStack incident and the Checkmarx Jenkins AST plugin intrusion incident were actually part of a well-planned coordinated supply chain attack campaign by the same threat group, TeamPCP.

Security researchers from Wiz, Snyk, and Socket have dubbed this large-scale, multi-targeted attack campaign (expected to launch in May 2026) the “Mini Shai-Hulud” worm attack. While the two incidents targeted different environments and used different initial entry points, they both originated from the same threat group, malware family, infrastructure, and ultimate target.

Incident details: The previous version of the Checkmarx Jenkins AST plugin (specifically version 2026.5.09) was compromised as part of an ongoing supply chain attack by the threat actor group TeamPCP, following their earlier compromise of Checkmarx infrastructure in March 2026.

The attack appears to be another TeamPCP incident because the attackers used the same techniques—gaining unauthorized access to Checkmarx’s GitHub repositories—to inject credential-stealing “Dune-themed” malware, similar to the previous KICS and GitHub Actions attacks.

Official announcement: Please refer to the link for details. – https://checkmarx.com/blog/ongoing-security-updates/

Cell Phone (iPhone, Android, windows mobile), Under our observation

Closer Look – SIM-Farm-as-a-Service (28th Apr 2026)

Leave a comment

Preface: A SIM box (or SIM bank) is a hardware device that houses multiple SIM cards simultaneously to facilitate VoIP-to-GSM call termination. It reroutes international VoIP calls to appear as local calls by using local prepaid SIM cards, allowing operators to bypass high international tariffs and exploit low local call rates. It is primarily used for, but not limited to, fraudulent bypass.

Background: Why SIM-Farm-as-a-Service (SFaaS) is a Major Security Concern

Industrial-Scale Fraud: It enables the mass creation of fake accounts for social media, messaging apps, and banking by bypassing SMS-based one-time password (OTP) verification.

Evading Detection: By using local SIM cards, scammers can disguise international phishing attempts as local calls or texts, making them harder for users and automated systems to detect.

Critical Infrastructure Risk: Massive setups, like the one dismantled by the US Secret Service in late 2025, have the capacity to overload cellular networks, potentially jamming emergency services.

Legal Gray Areas: While the hardware itself is often legal for testing purposes, its application in SFaaS models has prompted governments, notably the UK government, to pursue bans on the “possession and supply” of SIM farm equipment.

Security focus: The recent spotlight on SIM-Farm-as-a-Service in April 2026 stems from a major investigation by the cybersecurity firm Infrawatch. Please refer to the link for referene.

https://www.techradar.com/pro/sim-farm-as-a-service-how-a-belarus-based-network-hijacked-uk-and-us-telcos-to-enable-global-fraud

Potential Risk of CVE, Under our observation

AMD ID: AMD-SB-7050: About Vector Value Injection in AMD CPUs, AMD believes that existing mitigation guidance for FPVI remains valid and covers VVI cases as well. What are your thoughts on this? (18th Mar 2026)

Leave a comment

Background: The researchers’ paper introduces Vector Value Injection (VVI), which could allow an attacker with a deep understanding of microarchitectural behavior to inject values into vector registers during transient execution. Although they noted similarities with Floating Point Value Injection (FPVI), they reported Vector Value Injection as a new issue due to its capability to be triggered without denormal values as inputs.

AMD believes that VVI falls within the existing scope of CVE-2021-26314 (FPVI) as existing descriptions of FPVI do not specifically require denormal inputs. Additionally, AMD believes that existing mitigation guidance for FPVI remains valid and covers VVI cases as well.

Ref: CVE-2021-26314 – Potential floating point value injection in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution with incorrect floating point results, may cause the use of incorrect data from FPVI and may result in data leakage.

Official announcement: AMD ID: AMD-SB-7050 “Vector Value Injection in AMD CPUs”. Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7050.html

CVE-2021-26314 is a vulnerability from five years ago; however, in today’s parallel environment, the situation may be different!

How does Parallel Processing handle “Different Types”?

When tasks are different (e.g., one calculates Pi, one downloads a file, one reads a database), the system handles them in three ways:

1.         Heterogeneous Task Assignment (Asynchronous):

Instead of using a “map” (which does the same thing to many items), we use apply_async. This allows Core 1 to run a “Math” function while Core 2 runs a “Data Backup” function simultaneously.

2.         OS Scheduling & Context Switching:

The Operating System (OS) is the “manager.” If Task A is waiting for a slow Hard Drive (I/O Bound), the OS immediately moves Task B (CPU Bound) onto that core so no time is wasted.

3.         Hardware Resource Partitioning:

On a chip like the 9995WX, different execution units inside the core can work at once. One part of the core handles Integer math, while another handles Floating Point (AVX-512). This allows the processor to crunch different types of data within the same clock cycle

Vector Value Injection integrated to pool.apply_async (which runs different functions simultaneously) cannot be curcumvented through Register Scrubbing or Control-Flow Enforcement (CET). In fact, manually assigning different functions using `apply_async’ lowers the defense level potentially.

Why apply_async May Lower the Defense Level?

When you use pool.apply_async to launch different functions, Python’s multiprocessing creates multiple independent OS Processes.

•          Expanded Attack Surface: Compared to a single-process loop, a multi-process environment increases the frequency of Inter-Process Communication (IPC). If an attacker leverages Vector Value Injection, they can hunt for vulnerabilities in the different logic paths of each unique function.

•          Context Switching Risks: Frequent task scheduling can increase the risk of Cache Side-channel leaks. These leaks can sometimes bypass Register Scrubbing protection by capturing data before it is cleared.

End of article

AI and ML, Under our observation

Edge TPU (an ASIC accelerator developed by Google) – Episode 1 (23rd Feb 2026)

Leave a comment

Preface: PyCoral is specifically a TPU processing technique. While TensorFlow Lite (TFLite) can run on a standard CPU, PyCoral is the dedicated library used to delegate those operations to the Edge TPU hardware.

PyCoral API: This is a Python library specifically designed by Google to run inference on Coral Edge TPU hardware, such as the Coral USB Accelerator or M.2 modules. It is built on top of TensorFlow Lite.

Nvidia H100: This is a high-end data center GPU based on the Hopper architecture. It uses Nvidia’s proprietary software stack, including the CUDA toolkit, TensorRT, and the Transformer Engine to accelerate AI workloads.

Background: It is accurate to say that foundational memory management principles—specifically allocation and copying (malloc/new, memcpy)—are the basis for both CUDA/TensorRT and Coral API inference, though they operate on different memory spaces.

  • CUDA/TensorRT (GPU-centric): Uses cudaMalloc and cudaMemcpy to manage dedicated GPU device memory.
  • PyCoral API/TFLite (CPU-centric/Edge): Primarily uses malloc or new for CPU-based input/output buffers and memcpy to manage memory within host memory, even when interacting with the Edge TPU.

In both cases, efficient management of data movement between host (CPU) and device (GPU/TPU) is key, making memory allocation and copying the common denominator.

PyCoral API (pycoral module): This is a Python library built on top of the TensorFlow Lite Python API (tflite_runtime). It provides convenience functions and additional features (like model pipelining and on-device transfer learning) to simplify development with Python.Coral C++ API (libcoral): This is a C++ library built on top of the TensorFlow Lite C++ API. It offers the same functionality as the PyCoral API but for C++ applications.

Cyber security focus: But the most common vulnerability occurs when developers call [.]get() to obtain the raw pointer, and then continue to use that raw pointer after the std::unique_ptr has gone out of scope or been destroyed. Is the C++ TPU programming related to this issue? Please refer to the recommendations in the diagram for details.

Under our observation

Learn more about AMD ID: AMD-SB-3042 (Control Flow Reconstruction using HPCs) [18 Feb 2026]

Leave a comment

Preface: AMD EPYC processors are extensively used for High-Performance Computing (HPC) clusters, powering some of the world’s most advanced supercomputers. They are specifically engineered to handle compute-intensive tasks such as scientific simulations, weather forecasting, and complex molecular modelling.

Background: AMD Infinity Guard is a suite of security features built directly into the silicon of the AMD EPYC processor. While it interacts with and protects firmware, its foundation is hardware-based. When AMD Infinity Guard forms Secure Encrypted Virtualization (SEV), the encryption keys are not stored on an external hard disk or in standard bare-metal memory. Instead, they are kept entirely within the processor’s hardware. The actual data belonging to your virtual machine is stored in the system’s “bare-metal” RAM (DRAM), but it is fully encrypted.

In a traditional setup, the hypervisor has “God mode”—it can see everything. With AMD SEV-SNP, the hardware creates a Trusted Execution Environment (TEE) where the hypervisor is demoted to a simple “data mover” that is cryptographically blocked from the VM’s secrets.

Ref: CounterSEVeillance is a novel side-channel attack that targets AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging), a technology designed to protect confidential virtual machines (VMs) from a malicious hypervisor. Unlike previous attacks that might manipulate the VM’s state, CounterSEVeillance is primarily a passive side-channel attack, making it difficult to detect. 

Official article details

Summary: Researchers from Universities of Durham and of Luebeck have reported a way for a malicious hypervisor to monitor performance counters and potentially recover data from a guest VM. 

Affected Products and Mitigation: Performance counters are not protected by Secure Encrypted Virtualization (SEV, SEV-ES, or SEV-SNP).  AMD has defined support for performance counter virtualization in APM Vol 2, section 15.39. Performance Monitoring Counters (PMC) virtualization, available on AMD products starting with AMD EPYC™ 9005 Series Processors, is designed to protect performance counters from the type of monitoring described by the researchers.

For processors released prior to AMD EPYC™ 9005 Series Processors, AMD recommends software developers employ existing best practices, including avoiding secret-dependent data access or control flows where appropriate to help mitigate this potential vulnerability.

Official announcement: Please refer to the link for details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3042.html

Under our observation

AMD ID: AMD-SB-8022 – Closer look in Optical Probing of Readback CRC Bus (13th Feb 2026)

Leave a comment

Preface: AMD 7000 series (7-series) processors are extensively used to build High Performance Clusters (HPC). AMD provides 7-series solutions for both enterprise-grade and consumer/prosumer levels:

  • AMD EPYC™ 7002 and 7003 Series: These server-grade processors (codenamed “Rome” and “Milan”) are specifically designed for commercial and scientific HPC. They offer up to 64 cores per socket, high memory bandwidth (8 channels), and extensive PCIe Gen4 lanes to reduce data bottlenecks.
  • AMD Ryzen™ 7000 Series: While typically consumer CPUs, they are often used for “personal HPC” or small-scale clusters due to their high clock speeds and performance-per-dollar for specialized parallel computing tasks.

Background: The “Readback CRC Bus” refers to the internal logic path or mechanism in FPGAs (especially AMD/Xilinx devices) used to perform readback cyclic redundancy checks.

This is not a physical external “bus,” but a key component of the configuration logic, primarily used to ensure the data integrity of the FPGA’s internal configuration memory. Its core functions.

Academic studies and AMD’s bulletin describe attacks where researchers collect near‑infrared photon emissions that escape from transistor switching events on the FPGA die.

This depends on silicon’s bandgap (~1.1 eV ⇒ transparent above ~1100 nm). Because of this:

  • Visible light cannot pass through silicon.
  • Near‑IR and SWIR (1.1–2.3 µm) passes through with relatively low attenuation.
  • The plastic/epoxy package is often more opaque, so attacking from the backside of a thinned die is normal.

The reason backside emissions are detectable:

  • switching transistors emit very weak photons,
  • silicon becomes transparent above ~1100 nm,
  • the backside offers a direct path to the active circuitry after thinning,
  • the metallization layers on the front side block light.

This is the same principle used in IRIS inspection methods, which also rely on silicon’s IR transparency for imaging.

Technical Summary: By leveraging a physical optical side channel, an attacker could recover plaintext configuration data from encrypted bitstreams. AMD recommends maintaining good physical security practices and keeping  systems closed unless needed for maintenance and repairs by authorized personnel.

 Affected Products and Mitigation: The testing by the academics was done on AMD Xilinx 7 series FPGAs. This is a physical back side attack and is outside of the threat model for AMD 7-series FPGAs.

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

Under our observation

AMD ID: AMD-SB-6026 – AMD does not believe that the reported vulnerability exists within the MI3XX GPU designs. (12th Feb 2026)

Leave a comment

Preface: The MI3xx series (specifically the AMD Instinct MI300 and MI350 series) is designed and manufactured by AMD. These chips are not traditional graphics cards for gaming; they are high-performance GPU accelerators specifically designed for Generative AI, large-scale AI training, and High-Performance Computing (HPC).

Background: In the AMD Instinct MI300A architecture, the cache is technically known as the MALL (Memory Attached Last Level) cache. While “MIG” is a term commonly associated with NVIDIA’s Multi-Instance GPU technology, the MI300A’s shared last-level cache is officially branded as the AMD Infinity Cache.

Is L3/Limited-Level Cache (LLC) shared across all cores?

  • GPU L3/Infinity Cache (MALL)
  • Shared across all clients (CPU & GPU).
  • The MI300A features a massive 256 MB shared Last-Level Cache (LLC), often called the AMD Infinity Cache or MALL (Memory Attached Last Level).

This specific cache is located on the I/O Die (IOD) and sits beyond the coherence point, meaning it is accessible by both the 24 CPU cores and the 228 GPU Compute Units.

  • The MI300A uses a truly shared last‑level cache (MALL).
  • Shared caches always raise the theoretical possibility of side channels.
  • But only if an attacker can cause and observe measurable eviction‑based interference.
  • AMD claims their virtualization model prevents this for GPU workloads.

Ref: NVIDIA H100 GPUs with Multi-Instance GPU (MIG) enabled provide full hardware-level isolation, ensuring that each partitioned “GPU Instance” (GI) has its own dedicated high-bandwidth memory (HBM3), compute cores, and L2 cache. Each MIG instance has its own independent path through the memory system, including dedicated cross-switch ports, L2 cache groups, memory controllers, and DRAM address buses. Many cache-based side-channel attacks rely heavily on the time delays (latency differences) associated with accessing memory in the L2 (or L3/LLC) cache.

Security Focus: The researchers shared with AMD a report titled “Behind Bars: A Side-Channel Attack on NVIDIA H100 MIG Cache Partitioning Using Memory Barriers”.

Based on MI3XX GPU architectural analysis, AMD has determined that the Guest VM-initiated operations of kernel launch related memory operations only impact the local XCD partition spatially allocated to the Guest VM and do not result in any observable interference on any other Guest VM load operations. Therefore, AMD does not believe that the reported vulnerability exists within the MI3XX GPU designs.

Official announcement: Please refer to the link for more details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6026.html