Checkmarx Jenkins AST Plugin Compromised (14th May 2026)

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/

Shai-Hulud operates as a multi-vector, self-propagating worm. It routinely changes its entry points to compromise environments. Stay vigilant! (14th May 2026)

Preface: The TanStack incident was a highly sophisticated software supply-chain compromise that occurred on May 11, 2026. An attacker successfully hijacked TanStack’s legitimate GitHub Actions release pipeline to publish 84 malicious versions across 42 @tanstack/* npm packages, including widely used tools like @tanstack/react-router.

Background: Both @tanstack/react-router and @tanstack/react-query are client-side frontend libraries and K8s is a backend orchestration platform. In normal circumstances, Frontend applications running inside Kubernetes (K8s)-managed containers are typically containerized web assets (static files or server-side rendered apps) packaged with a lightweight web server (like Nginx or Apache). But @tanstack/react-router and @tanstack/react-query are highly relevant to building robust frontend applications that run inside a K8s-managed containerized. These tools handle frontend data fetching and routing, while Kubernetes manages the infrastructure, pods, and scaling of the APIs they consume. TanStack Query handles caching and server state synchronization, reducing unnecessary API calls to backend services running on K8s. You can call @tanstack/react-router and @tanstack/react-query part of a suite. They are core components of the TanStack suite, a collection of high-quality, open-source libraries designed for modern web development.

Incident details: A supply chain attack, dubbed as “Mini Shai-Hulud”, is affecting well-known projects including TanStack, Mistral AI, UiPath, and OpenSearch.

Official announcement: Please refer to the link for details – https://digital.nhs.uk/cyber-alerts/2026/cc-4781

CVE-2026-43284: Dirty Frag tricks the IPsec/TCP stack into doing the “dirty work”(13th May 2026)

Preface: The “Dirty Frag” attack chains two separate flaws in the Linux kernel’s networking stack: one in the ESP(Encapsulating Security Payload) protocol used by IPsec and another in the RxRPC protocol used for the AFS distributed file system. If you do not use IPsec, disabling its modules removes one of the major attack paths.

Background: The “Dirty Frag” vulnerability is deemed difficult to patch immediately due to its exploitation of a long-standing core Linux kernel optimization, which initially lacked official, widespread patches upon disclosure. While disabling ESP modules helps, effective mitigation requires blacklisting both ESP and RxRPC modules, or patching the kernel directly.

How to mitigate vulnerabilities:

Step 1:Block the ESP and RxRPC modules: Create a configuration file (e.g., /etc/modprobe.d/dirtyfrag.conf) to ensure the modules cannot be auto-loaded by an exploit:

bash

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Step 2:Unload current modules: Remove the modules if they are currently active in memory:

bash

sudo modprobe -r esp4 esp6 rxrpc
 

Step 3:Clear the Page Cache: The exploit works by corrupting the page cache. After applying the blocks, clear the cache to ensure no malicious changes persist in RAM:

bash

sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
 

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

How can Apple meet requirements for lawful key escrow similar to those in Canada’s C-22 Act? (12th May 2026)

Preface: Can we say that Apple’s iPhone is the most secure smartphone in the world? Yes, the Apple iPhone is widely considered the most secure mainstream smartphone for general users, largely due to its “walled garden” approach.

Background: As of May 2026, Canada’s proposed Bill C-22, the Lawful Access Act (2026), is currently being debated in the House of Commons. Apple Inc. has formally opposed the legislation, warning that it could legally compel the company to weaken encryption on its devices and build “backdoors” for government surveillance.

Point of view: Why the “Standard Procedure” Fails for Escrow?

The code provided (see attached diagram) is designed for user-controlled security, which is functionally opposite to government-authorized access:

  • Hardware Isolation: Refer to code, the private key is generated inside the Secure Enclave and never leaves it. It is physically impossible to “escrow” (copy and store elsewhere) a private key generated this way.
  • The “Encrypted Blob” Problem: Step 4 of code (privateKey.dataRepresentation) creates an encrypted reference to the key, not the key itself. This blob can only be decrypted by the same Secure Enclave that created it. To “escrow” this for the Canadian government, Apple would need to fundamentally redesign the SEP to allow external decryption—creating the very “systemic vulnerability” they are currently fighting in the House of Commons.

Headline news: Please refer to the link for details – https://www.cbc.ca/news/politics/apple-argues-liberals-lawful-access-bill-could-put-users-personal-data-at-risk-9.7190092

CVE-2026-0300: Best practice guidelines remediate design weakness for PAN-OS software (11th May 2026)

Preface: Nginx in PAN-OS assists in routing traffic to backend management components, such as those responsible for user authentication and Captive Portal functionality.

Background: Palo Alto Networks firewalls can intercept HTTP and HTTPS traffic from unauthenticated users and redirect them to an internal web server (the Authentication Portal) to collect credentials and establish a user-to-IP mapping.

This feature, now known as the Authentication Portal (formerly Captive Portal), is designed to enforce security policies based on user identity, particularly for guest or BYOD users.

Vulnerability details: A buffer overflow vulnerability in the User-ID™ Authentication Portal (aka Captive Portal) service of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to execute arbitrary code with root privileges on the PA-Series and VM-Series firewalls by sending specially crafted packets. The risk of this issue is greatly reduced if you secure access to the User-ID™ Authentication Portal per the best practice guidelines.

Why is CVE-2026-0300 Rated So High?

Even though it involves the User-ID Authentication Portal, which is not always internet-facing, it receives a near-perfect score because:

  • Unauthenticated Root Access: An attacker does not need to be an admin. They simply send specially crafted packets to the portal to trigger a buffer overflow.
  • Zero Interaction: The attack happens silently without any user having to click a link or log in.

High Impact: Once exploited, the attacker gains root control of the firewall. According to Unit 42, attackers have used this to enumerate Active Directory, steal credentials, and destroy logs.

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

Impacted Devices:

  • PA-Series and VM-Series firewalls.
  • Prisma Access and Cloud NGFW are reported to be unaffected

CVE-2026-25293 – Incorrect authorization in PLC FW (7th May 2026)

Preface: Qualcomm chipsets contain Powerline Communication (PLC) firmware features, particularly within their automotive and IoT-focused product lines designed for smart grid and electric vehicle (EV) charging.

Background: To implement write protection for SPI Flash, you generally need a combination of Hardware WP# pins and Software Status Register configurations.

The SPI Flash physical and software protection bits (BP bits / WP# pin) failed to provide a complete write-lock across the device lifecycle.

The threat model for CVE-2026-25293 usually assumes an attacker targets the PIB (Parameter Information Block):

•       Malicious PIB Modification: If WP is not active, an attacker can change MAC addresses or security keys in the PIB to conduct Man-in-the-Middle (MITM) attacks and steal charging credentials.

•       Persistent Backdoor: By overwriting sections of the NVM code (made possible because BP bits = 0), an attacker can implant a persistent backdoor that survives a reboot.

Vulnerability Details:

Title – Incorrect authorization in PLC FW

Description – Buffer overflow due to incorrect authorization in PLC FW

Technology Area – PLC FW

Vulnerability Type – CWE-863

Access Vector – Remote

Security Rating – Critical

Official announcement: Please refer to the link for details – https://docs.qualcomm.com/securitybulletin/may-2026-bulletin.html

Remedy: The primary remedy is to update the affected PLC firmware to the latest version supplied by the vendor that specifically addresses this CVE.

CVE-2026-25254: Improper authorization in Qualcomm Software Center (6th May 2026)

Preface: Even though QSC is installed on your Windows or Linux PC, its primary mission is to manage the Linux operating system that lives on your Target Development Board. QSC v1.21.0 knows exactly how to handle projects based on “Long Term Support Kernels” and provides the specific tools and patches required for them.

Background: To enable this within your qsc-cli workspace, follow these steps to modify your build configuration:

Step 1. Log in to the CLI
bash

qsc-cli login -u <your_email_address>

Step 2. In the context of the Qualcomm QRB4210 (RB2) and the Qualcomm Linux SDK, “enabling the SocketIO interface” typically refers to configuring a high-speed communication transport layer used in the Robot Operating System (ROS) or for high-speed sensor data between subsystems.

To enable this within your qsc-cli workspace, follow these steps to modify your build configuration:

Step 3. Identify the Required Metadata Layer

Socket-based transport optimizations, such as QRB ROS transport for zero-copy message passing, are often contained in the Qualcomm Intelligent Robotics (QIRP) SDK layers. Ensure you have the meta-qcom-qirp (or similar) layer in your workspace

Step 4. Update your bblayers.conf

Step 5. Enable via Kernel Menuconfig (If Hardware Socket/Interface)

If you are referring to a specific hardware-backed socket interface (like a virtualized socket for a DSP or NPU), you may need to enable it in the kernel:

Enter your build environment via qsc-cli.

Run the devtool to modify the kernel configuration:

Bash

devtool menuconfig linux-qcom-base

Search (using /) for SOCKET or the specific interface driver name (e.g., AF_QIPCRTR for Qualcomm IPC Router sockets).

Set it to <*>

Vulnerability details: Improper authorization in Qualcomm Software Center

Description : Improper authorization leads to Remote Code Execution via SocketIO interface.

Official announcement: Please refer to the link for details –

https://docs.qualcomm.com/securitybulletin/may-2026-bulletin.html

To address the vulnerability identified in CVE-2026-24222 (and the related SSRF risk in CVE-2026-24231) – 5th May -2026

Preface: While NVIDIA has not “dropped” support for the core OpenClaw framework, in some specific cases they have moved away from its standard form.

Background: Because NemoClaw “bakes” certain variables into the sandbox configuration during onboarding, if they are not correctly scoped or sanitized, they remain accessible to the agent process even though it should be isolated.

As a result, this allows an attacker to exfiltrate critical secrets (like the NVIDIA_API_KEY or TELEGRAM_BOT_TOKEN mentioned) through the agent’s existing communication channels.

To address the vulnerability identified in CVE-2026-24222 (and the related SSRF risk in CVE-2026-24231), admin should use the following CLI flags during sandbox creation or update. These flags, introduced in NemoClaw v0.0.18, are designed to strictly control which host environment variables are “baked” into the sandbox environment.

For details, see attached diagram.

Vulnerability details:

CVE-2026-2422 NVIDIA NemoClaw contains a vulnerability in the sandbox environment initialization component where a remote attacker may cause improper access control by sending prompt-injected content that causes the agent to read and exfiltrate host environment variables not properly restricted during sandbox creation. A successful exploit of this vulnerability may lead to information disclosure.

CVE-2026-24231 NVIDIA NemoClaw contains a vulnerability in the validateEndpointUrl() SSRF protection component where an attacker may cause a server-side request forgery by supplying a crafted endpoint URL referencing the 0[.]0[.]0[.]0/8 address range via a blueprint configuration file or CLI flag. A successful exploit of this vulnerability may lead to information disclosure.

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

Recommended Action:
NVIDIA has released a software update for NVIDIA NemoClaw to address this issue. Users should update to version v0.0.18 or later immediately, as the privilege escalation fixes are critical.

CVE-2026-31431: Copy Fail, a module designed to ensure security (encryption), has become a tool used to undermine security (4th May 2026)

Preface: The algif_aead module is a Linux-specific component of the AF_ALG socket interface. It is rarely the primary choice for application-level encryption even on Linux, and it has no direct equivalent in the architecture of Apple’s iOS XNU kernel.

Background: The use of algif_aead is a niche architectural choice for several reasons:

Platform Dependency: It is part of the Linux Kernel Crypto API. Apps targeting multiple platforms (Android, iOS, Windows) prefer cross-platform libraries like OpenSSL, BoringSSL, or libsodium to avoid writing platform-specific kernel interface code.

The specified design weakness (Copy Fail) in the Linux kernel allows a local attacker to overwrite read-only files by manipulating the page cache via splice() and the AF_ALG (kernel crypto) interface.

Ref: This exploit allows a write to the page cache of that file. This explains how a read-only file gets “overwritten” in memory, which is the “magic” of this vulnerability.

Vulnerability details: In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead – Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.

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

The “ghost data” issue has been fixed in iOS 18.7.8 and iPadOS 18.7.8, as well as iOS 26.4.2 and iPadOS 26.4.2 on 24th Apr 2026. Did you receive same update alert again on 1st of May 2026? (2nd May 2026)

Preface: My iPhone 15 pushed the iOS 26.4.2 update again on May 2, 2026. I think even if you installed it around April 24—is likely because Apple released a revised build of that same update to address continued issues, or my device failed to properly register the previous installation due to the emergency nature of the patch.

Background: Why I received the update again on 1st May 2026. The NVD’s last modified date is shown as April 29, 2026. Therefore, this is one of the reasons why I need to perform the analysis again. Why update again? Similar to previous scenarios in 2023, Apple often re-issues critical patches if the first version did not fully resolve the issue, was causing compatibility problems, or if new information about the vulnerability arose.

My observation: The April 29 update reinforces why your switch to PRAGMA secure_delete = ON; is the right move. The official fix description—”improved data redaction”—aligns with the behavior of secure_delete, which physically overwrites data to ensure it cannot be recovered via forensic tools.

By using the PRAGMA, you are implementing at the application level what Apple has now implemented at the OS level: ensuring that when a record is “deleted,” its physical remnants are immediately destroyed.

The following URL is the analysis report I published on April 24, 2026 – http://www.antihackingonline.com/cell-phone-iphone-android-windows-mobile/the-ghost-data-issue-has-been-fixed-in-ios-18-7-8-and-ipados-18-7-8-as-well-as-ios-26-4-2-and-ipados-26-4-2-24th-apr-2026/

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

antihackingonline.com