Security Advisory: CrackArmor (AppArmor Vulnerabilities)

1. Definition

CrackArmor is the collective name for a suite of nine vulnerabilities discovered in the Linux kernel’s AppArmor security module, disclosed in March 2026. These flaws represent a significant breakdown in the kernel's access control mechanisms, allowing an unprivileged local attacker to bypass security boundaries, trigger a Denial of Service (DoS), or achieve a full Local Privilege Escalation (LPE) to root.

2. How It Works

The core of the CrackArmor suite is a classic "confused deputy" vulnerability located within AppArmor’s interface for managing security profiles. AppArmor uses several pseudo-files (such as .load, .replace, and .remove) found within the securityfs filesystem (typically at /sys/kernel/security/apparmor/).

The vulnerability stems from two critical oversights:

• Permissions Mismatch: These control files were mistakenly set to be world-writable. While the kernel eventually checks for root privileges when data is written, it fails to perform a rigorous check at the moment the file is initially opened.

• The Exploit: An attacker can open one of these files and then "trick" a highly privileged program—the "deputy"—into writing to it. For example, by using sudo or su in a way that redirects output to the already-open file descriptor, an attacker can force the system to load a malicious security profile or delete existing protections, all without having the actual permissions to do so.

3. Impact

CrackArmor is particularly dangerous because it undermines the very tool (AppArmor) used to sandbox applications and containers. The impact is widespread, affecting millions of Linux deployments globally.

• Local Privilege Escalation (LPE): By loading a "fail-open" profile, an attacker can exploit a known interaction with sudo to execute arbitrary commands as the root user.

• System Instability (DoS): Attackers can load specifically crafted, deeply nested profiles that cause uncontrolled recursion in the kernel. This leads to stack exhaustion and a kernel panic, effectively crashing the host.

• Container Breakout: Because AppArmor is a primary line of defense for container runtimes (like Docker or LXD), these flaws allow an attacker to escape a containerized environment and gain access to the underlying host system.

• Information Leakage: Certain flaws allow for out-of-bounds reads of up to 64 KiB of kernel memory. This can be used to harvest sensitive data or bypass KASLR (Kernel Address Space Layout Randomization), facilitating more complex exploits.

4. Remediation

To mitigate the risk of CrackArmor, administrators must update their Linux kernel to the patched versions released in March 2026.

Furthermore, related userspace packages like sudo and util-linux must be updated to close known exploitation chains.

Note: A system reboot is required after the kernel update to ensure the fixes are active.

5. Conclusion

CrackArmor is a high-priority security risk. While it requires local access to the system, the ease with which it can be used to escalate privileges or crash infrastructure makes it a critical threat. Organizations are strongly advised to patch their fleets immediately, as Proof-of-Concept (PoC) code is circulating and active exploitation has been confirmed.

6. Documentation

• Ubuntu Security: CrackArmor Vulnerability Overview

• Qualys Security Blog: Technical Breakdown of CrackArmor

• Canonical Blog: AppArmor security fixes available

Security Advisory: CVE-2025-14847 (MongoBleed)

1. Definition

CVE-2025-14847 is a critical information disclosure vulnerability in the MongoDB Server network transport layer. It is a heap-based memory leak flaw that allows a remote, unauthenticated attacker to read fragments of the server's uninitialized memory.

2. How It Works

The vulnerability originates within the server's network transport layer, specifically during the handling of zlib-compressed messages. When a client initiates a connection, it can request that communication be compressed to save bandwidth. The flaw occurs because the MongoDB server's decompression routine fails to strictly validate the relationship between the size of the incoming compressed packet and the size of the memory buffer allocated to hold the resulting data.

An attacker exploits this by sending a specially crafted, malformed zlib packet that claims to be smaller than the space the server allocates for it. Because the server does not "zero out" or properly bound the returned data to the actual size of the decompressed payload, it mistakenly reads and transmits the contents of the adjacent uninitialized heap memory back to the attacker. This process allows the attacker to repeatedly "bleed" fragments of the server's RAM, which often contains sensitive data from previous operations or other users.

3. Impact

The severity of this vulnerability stems primarily from the fact that it can be triggered before any authentication takes place. This means that an anonymous attacker on the internet can probe a vulnerable MongoDB instance and begin extracting data without needing a username, password, or any valid session tokens. Because the memory "bled" by the server is uninitialized, it essentially serves as a random window into the server's active RAM.

This exposure is catastrophic for data privacy, as these memory fragments frequently contain highly sensitive information. Security researchers have confirmed that the leaked data can include plaintext database credentials, administrative API keys, environment variables, and fragments of actual BSON documents belonging to other users. MongoDB instances currently exposed to the public internet are at risk, the scale for potential exploitation is massive. Furthermore, since public Proof-of-Concept (PoC) code is already circulating and active exploitation has been confirmed, the window for remediation is closing rapidly for unprotected organizations.

4. Remediation

To mitigate this risk, administrators must update to the minimum patched version for their respective branch as listed below:

If immediate patching is not an option, you should immediately disable zlib compression by setting the --networkMessageCompressors configuration to none, snappy, or zstd.
Additionally, ensure that your firewall or Security Group rules restrict port 27017 to known, trusted IP addresses only.

5. Conclusion

CVE-2025-14847 is a high-priority risk, a patch for the MongoDB product has been deployed by Scaleway and has been deployed to its internal infrastructure.. Users are strongly advised to update as soon as possible because the vulnerability is being used in the wild.

6. Documentation

• https://nvd.nist.gov/vuln/detail/CVE-2025-14847
• https://thehackernews.com/2025/12/mongodb-vulnerability-cve-2025-14847.html
• https://www.wiz.io/blog/mongobleed-cve-2025-14847-exploited-in-the-wild-mongodb

Definition

The vulnerability, identified as CVE-2025-55182 or "React2Shell" is a severe unauthenticated remote code execution (RCE) flaw in the React Server Components "Flight" protocol. Rated with a critical CVSS score of 10.0, this issue allows an attacker to execute arbitrary code on servers utilizing React 19 and associated frameworks like Next.js that implement React Server Components.

How it works

The React Server Components (RSC) system, which relies on the Flight protocol for data serialization between the browser and server, contains a critical vulnerability in specific versions. This flaw involves the unsafe deserialization of specially crafted requests.
Attackers can exploit this vulnerability to gain control over internal objects essential for module resolution and callbacks. In the default configurations of React 19 and Next.js applications utilizing the App Router, this attack vector is particularly critical. It allows unauthenticated attackers to access powerful Node.js primitives, ultimately leading to arbitrary command execution.

Impact

The vulnerability allows for full remote code execution on the React server, posing a severe risk. Exploitation enables attackers to steal sensitive information, move laterally to internal systems, and establish persistent access to the cloud environment through the deployment of cryptominers or backdoors. This flaw is currently being actively exploited, including by threat groups with state affiliations.

Fix

For React Server Components:
Update react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack from versions 19.0–19.2.0 to the patched versions:

• 19.0.1
• 19.1.2
• 19.2.1

For Next.js App Router:
Upgrade to one of the following minimum versions:

• 15.0.5
• 15.1.9
• 15.2.6
• 15.3.6
• 15.4.8
• 15.5.7
• 16.0.7

After upgrading, redeploy all affected services.

Conclusion

Immediate Action:

• Inventory: List all React/Next.js workloads.
• Patch: Apply patches to all React Server Components (RSC) services.
• Contain: Restrict public access to vulnerable services if possible.
• Security: Review logs for unauthorized execution, rotate exposed secrets, and increase monitoring on unpatched systems.

Documentation

• React team advisory – Critical Security Vulnerability in React Server Components (React)
• GitHub advisory – GHSA-fv66-9v8q-g76r (official package and patch details) (GitHub)
• NIST - National Vulnerability Database (NIST)

Definition

CVE-2025-49844, also known as RediShell, is a critical remote code execution (RCE) vulnerability affecting Redis through its embedded Lua scripting engine. A malicious, authenticated client can execute crafted Lua scripts to escape the sandbox and gain full control of the host.

How it works

This attack allows an authenticated user to send a malicious Lua script, leading to arbitrary code execution outside the Redis Lua interpreter sandbox. This, in turn, grants unauthorized access to the underlying host. The technical process involves:

• Memory Corruption: Specially crafted Lua scripts manipulate the garbage collector to free memory still referenced by active objects.
• Sandbox Escape: The resulting use-after-free condition enables code execution beyond the Lua sandbox.
• Host Access: Attackers achieve native code execution on the Redis host system.
  Once a Redis host is compromised, attackers can steal credentials, deploy malware, extract sensitive data from Redis, move laterally to other systems, or use the stolen information to gain access to cloud services.

Impact

Attackers can exploit authenticated (or misconfigured/unauthenticated) Redis instances to execute arbitrary code, steal or alter data, and potentially compromise the host. Given Redis widespread use, particularly in cloud and container environments, this vulnerability presents a significant attack surface.

Fix

To address the Redishell vulnerability, upgrade Redis to one of the following patched versions: 6.2.20, 7.2.11, 7.4.6, 8.0.4, or 8.2.2.
If an immediate upgrade is not feasible, mitigate the risk by disabling Lua commands (EVAL, EVALSHA) through ACLs and by limiting Redis access to trusted networks only.

Conclusion

Organizations must immediately patch, audit configurations, and tighten ACLs to prevent exploitation of CVE-2025-49844. This critical vulnerability has broad exposure and active Proof-of-Concept (PoC) code.

Documentation

For more information and updates on these CVEs, refer to the following links:

• Redis Security Advisory
• GitHub Security Advisory
• National Vulnerability Database
• Redis Commit Fix

Definition

CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 and CVE-2025-1974 are vulnerabilities affecting Ingress NGINX Controller for Kubernetes.

Those vulnerabilities result in an unauthenticated remote code execution that can lead to a cluster takeover.

How it works

To be vulnerable, one must use an ingress NGINX Controller.

When using ingress NGINX, an admission controller is deployed within pods. Their purpose is to validate incoming ingress objects before they're deployed. The issue is that admission controllers are accessible by default over the network without authentication. This lack of authentication gives the opportunity to an attacker to inject an arbitrary NGINX configuration remotely by sending a malicious ingress object directly to the admission controller via the network.

Once the admission controller receives the object, it constructs an NGINX configuration from this latter and validates it via the NGINX binary. During this validation phase, the injected configuration causes the NGINX validator to execute code, leading to a remote code execution on the ingress NGINX controller's pod.

The elevated privileges and unrestricted network accessibility can lead to an access to all the cluster's secrets across namespaces, and thus, possibly, to a complete cluster takeover.

Impact

Ingress Nightmare has a critical impact of security:

• It allows attackers to perform remote code execution that can lead to a cluster takeover.

Detection

Check if you're using Ingress NGINX. For instance, by running this command :

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

the affected version of ingress NGINX are :

• < v1.11.0
• v1.11.0 - 1.11.4
• v1.12.0

Fix

• Update Ingress NGINX Controller to the latest version
• Ensure the admission webhook endpoint is not exposed externally.

⚠️ If you cannot perform an upgrade at the moment :

• Enforce network policies in a way that only the Kubernetes API can access the admission controller.
• Temporarily disable the admission controller component of Ingress NGINX.

Conclusion

Ingress Nightmare is based on 5 vulnerabilities: CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 and CVE-2025-1974.

The exploitation of those vulnerabilities leads to unauthorized access to all secrets stored across all namespaces in the Kubernetes cluster by attackers, which can result in cluster takeover.

Finally, it’s worth noting that a POC has been released.

Documentation

Kubernetes Issues :

• https://github.com/kubernetes/kubernetes/issues/131006
• https://github.com/kubernetes/kubernetes/issues/131007
• https://github.com/kubernetes/kubernetes/issues/131008
• https://github.com/kubernetes/kubernetes/issues/131009
• https://github.com/kubernetes/kubernetes/issues/131005

POC :

• https://github.com/sandumjacob/IngressNightmare-POCs

Complete report

• https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities