CISA confirms exploitation of a Linux firewall flaw. Check if your systems need the fix. ×ばつ
Get the latest Linux and open source security news straight to your inbox.
A GitHub Enterprise Server security fix addresses a way to turn the appliance's notebook viewer into a route to its own internal services. . GitHub disclosed the issue on September 22. An attacker with network access could use response timing to recover an instance secret and, through a second interaction, run code on the appliance. The company has published updates for six supported branches. This is a flaw in the self-hosted Enterprise Server product, not a claim that GitHub.com accounts are affected. The appliance can sit behind an organization's own network controls, but those controls only change who can reach the vulnerable viewer. They do not correct the missing port check. Teams that expose an instance to partners or a broad internal network should account for that reach when scheduling the update. The distinction between public and private instances matters here. If private mode is off, the vulnerable path needs no login. If private mode is on, any authenticated user can reach it. In either case, the attacker must first be able to contact the server. A Port the Viewer Did Not Check When the notebook viewer fetched a URL, it checked the scheme and host. It left the port out of that decision. A URL could therefore keep an approved host while directing the server to a different port, including one used by an internal service on the appliance. The result is server-side request forgery, where a server reaches somewhere the requester could not reach directly. Ports identify services on a host. Checking only the host name made the URL appear to point back to the permitted appliance, while its port could select a service that ordinary users were not meant to contact. The notebook viewer made that request from inside the appliance's own network position. That explains why a URL feature, rather than a conventional login endpoint, could become an entry point. The response body was not displayed to the requester. GitHub's vulnerability advisory says the time an internal service took torespond could still disclose an instance secret, one character at a time. It also describes a separate interaction leading to code execution. That final path is not spelled out publicly. There is no basis in the advisory to say a particular repository, secret, or build was taken. Figure 1. The notebook viewer checked a URL’s host but not its port, enabling access to internal services. Illustration based on GitHub’s advisory . What Can an Attacker Actually Learn? The notebook viewer's response does not need to print a secret for the mistake to matter. A service may take measurably different time to answer depending on whether a guess matches the next character. Repeated requests can turn that difference into a timing oracle: the attacker tests candidate characters and compares how long the server takes. GitHub says that behavior can reveal an instance secret one character at a time. The advisory also identifies a separate path to code execution through internal-service interaction, but does not publish enough detail to reconstruct that step. The demonstrated boundary failure is therefore clear while the exact follow-on sequence remains limited to GitHub's description. This matters to a self-hosted code platform because internal services often assume the outside network cannot address them directly. The viewer made a request from inside that boundary on behalf of a user. A private-mode setting changes the entry requirement, while the omitted port check still permits the misdirected request for a user who can reach the feature. Find the Right Fixed Release The affected branches are 3.17, 3.18, 3.19, 3.20, 3.21, and 3.22. Their fixes are 3.17.21, 3.18.15, 3.19.12, 3.20.8, 3.21.6, and 3.22.1, respectively. Match the deployed branch to GitHub's release notes ; a branch number by itself does not establish that the fix is installed. The six branch-specific versions matter in organizations that maintain separate primary, test, and recovery appliances. A team may update its productioninstance but leave a standby image at an older patch level, ready to be brought online during an outage. The immediate inventory should therefore cover every reachable instance and its running release, rather than only the main service's planned maintenance ticket. After upgrading, verify the running release on every reachable instance, including recovery appliances. Limit access while maintenance is pending. If local evidence suggests misuse, preserve appliance and application logs and review access to the notebook-viewer endpoint. GitHub reports no confirmed exploitation or published indicators of compromise. A recovery appliance can become production during an outage. Keep every reachable GitHub Enterprise Server instance on its branch's fixed release, and verify the version it actually runs. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading Attackers Chain Artifactory Vulnerabilities to Take Over Repositories Risks of GitHub Repo Breach on Linux Supply Chain Security GitHub Actions Compromise CI/CD Supply Chain Risks Explored Why CI/CD Pipelines Became Targets in Software Supply Chain Attacks Linux Patching Best Practices: Designing a Patch Validation Workflow . A serious GitHub Enterprise Server flaw reveals risks of internal service exploitation allowing potential code execution.. GitHub Enterprise, internal service security, code execution risk, server flaw, request forgery__EOC__. Andrew Kowal
Seccomp limits which Linux system calls a process can make. . In Kubernetes, administrators usually choose a profile through the pod security context and expect the runtime to apply it when the container starts. Checkpoint restore complicates that sequence. CVE-2026-92574 says CRI-O can restore seccomp rules and no_new_privs, a Linux safeguard that blocks privilege gains when a new program runs, instead of enforcing the destination configuration. That means a pod can declare a restricted profile while the rebuilt process runs under different syscall rules. No active exploitation has been confirmed, but clusters using checkpoint restore need to verify enforcement rather than configuration alone. Seccomp Restricts the Linux Kernel Interface Applications use system calls to ask the kernel for services such as opening files, creating processes, changing permissions, or configuring networks. Seccomp filters let administrators limit that interface. A profile can allow common calls, reject unnecessary ones, or terminate a process that attempts a prohibited operation. That filter works alongside other Linux controls. Namespaces isolate resources, capabilities divide root privileges, and Linux Security Modules enforce access rules. By narrowing the kernel functions available to a compromised workload, it can make some attack paths harder to reach. Figure 1. A seccomp filter checks system calls before the kernel handles them, allowing or rejecting each request. Source: Terence Li . Kubernetes supports two common choices. RuntimeDefault uses the container runtime's built-in seccomp profile, while Localhost uses a profile stored on the Linux node. Either choice tells the runtime which filter to attach to a newly created process. Restore Changes When the Filter Is Chosen During a normal start, the runtime builds a process from the destination container configuration. Applying the selected filter is part of that creation path. During restore, CRIU reconstructs a process describedby checkpoint files. The saved state may include security attributes that existed before the workload reached the destination cluster. The CRI-O advisory says a malicious checkpoint may retain seccomp state that conflicts with the requested Kubernetes security context. A related containerd advisory warned that a restored process could run without the seccomp filters requested by the orchestrator. This creates a mismatch between the policy Kubernetes records and the state Linux actually enforces. The pod describes the intended filter, while the running process may carry a different one. Why no_new_privs Matters With Seccomp The no_new_privs setting tells Linux that a process and its descendants must not gain additional privilege through an executed program. This safeguard matters because a process should not apply a restrictive filter and then gain new privileges that invalidate the assumptions behind it. The CRI-O disclosure names no_new_privs alongside credentials, capabilities, and seccomp state. That matters because these controls work together. A restored process with an unexpected combination may be more permissive than the destination policy suggests. Checking only whether a seccomp profile name appears in Kubernetes does not reveal the complete effective state. How Administrators Can Verify the Destination Begin by finding clusters and namespaces where checkpoint restore is available. If the feature is not required, keep it disabled or reject checkpoint-based pod creation. Restrict who can restore workloads. A checkpoint can influence process security state, so permission to use one should be treated as a privileged administrative action. Allow checkpoint images only from controlled sources. Protect the system that creates them and retain provenance records linking the checkpoint to its source workload and policy. After restoration, inspect the running process. Linux exposes seccomp mode and no_new_privs in process status data under /proc. Compare thoseeffective values with the expected pod security context. Testing should include a syscall that the destination profile deliberately blocks. Run that check only in a controlled environment and use it to confirm behavior, not as the sole evidence of a safe restore. Update the container runtime according to its advisory. containerd disabled the affected CreateContainer restore path by default in fixed branches. CRI-O administrators should monitor vendor packages because the first disclosure did not name a released fixed version. Seccomp remains useful after checkpointing, but only if the intended filter is actually attached to the restored Linux process. For restored workloads, effective kernel state is the final source of truth. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading What Is Kubernetes Security? A Linux Admin’s Practical Guide Securing Kubernetes and Cloud-Native Environments through DevSecOps How to Check Docker Container Isolation in Linux Kata Containers Flaw Weakens Container Security With Host-Chosen Mounts Improving Container Security Using Seccomp Runtime Hooks . Kubernetes admins need to review seccomp settings post-container restoration to ensure security compliance and safety. Kubernetes Security, Seccomp Enforcement, Container Security__EOC__. Dave Wreski
Privilege escalation in a container does not always begin with a new exploit. . A checkpoint restore can reintroduce Linux capabilities, the smaller permissions that divide up root's power, even when destination policy was supposed to remove them. That is the risk behind CVE-2026-92574 in CRI-O and a related containerd disclosure. CRI-O and containerd are runtimes that start and manage containers for Kubernetes. Both cases show how restored process state can disagree with the security configuration Kubernetes records. The danger depends on permissions and runtime features. Still, the mechanism matters because Linux enforces the capabilities held by the running process, not the safer capability set written in a pod specification. Linux Capabilities Are Part of Process Identity Traditional Unix systems treated root privilege as one broad switch. Linux capabilities divide many root powers into separate permissions attached to processes and executable files. Examples include changing file ownership, administering network settings, loading certain kernel resources, and bypassing some file access checks. Containers often start with a reduced capability set and drop more capabilities when the workload does not need them. Figure 1. Linux capabilities split specific privileges from the broader root permission model. Source: Techiescamp . This reduction is one of the practical boundaries between a normal application container and a highly privileged one. A process with a broad set of capabilities can reach kernel and host resources that a restricted process cannot. Capabilities also interact with user IDs, namespaces that isolate resources, executable files, and the no_new_privs safeguard that blocks privilege gains when a new program runs. Looking at one setting alone may not reveal what the process can actually do. Restore Can Preserve More Privilege Than Policy Allows A normal container start gives the runtime an opportunity to create a new process under the destinationsecurity context. The runtime can choose the user, drop capabilities, enable no_new_privs , and apply syscall filters. A checkpoint restore starts with saved process state. CRIU uses that state to rebuild the process as it existed before it was stopped. The CRI-O advisory says a malicious checkpoint can preserve credentials and Linux capabilities instead of enforcing the destination Kubernetes configuration. An attacker needs permission to create a pod from that checkpoint, so the flaw is not reachable through every workload. The policy conflict is the important part. A pod may request a non-root user and a small capability set, while the restored process resumes with broader authority from the checkpoint. Why Full Capabilities Change the Risk A container process with extra capabilities is not automatically equivalent to unrestricted root access on the host. Other controls still limit what the process can see, access, and request from the kernel. However, broad capabilities remove protections administrators deliberately rely on. Their impact grows when the container also has sensitive mounts, host namespaces, device access, or weak syscall filtering. The containerd advisory described a worst-case restored process running as root with full capabilities and no enforced seccomp filters despite restrictive policy. It also warned that status reporting could show requested settings rather than the actual restored state. That combination makes detection harder. Policy review may say the workload is restricted even when the Linux process holds more power. How to Check and Limit Restored Privilege First, restrict checkpoint restore permissions. Users who can deploy ordinary containers should not automatically be able to supply saved process state. Second, require trusted checkpoint provenance. Limit accepted registries, protect checkpoint creation systems, and reject unapproved checkpoint annotations with admission policy. Third, inspect effective capability sets afterrestoration. On the host, process status under /proc exposes capability fields for the running task. Inside an approved diagnostic context, tools such as capsh can help decode them. Compare the result with the capability set expected from the pod security context. A match in YAML is not sufficient if the running process differs. Fourth, review surrounding controls. Check the effective user, namespace membership, no_new_privs value, seccomp mode, mounts, and device access. Extra capabilities become more dangerous when another boundary is also weak. Finally, update the runtime according to vendor guidance. containerd patched supported branches by disabling the affected restore path by default. The initial CRI-O disclosure said branch fixes existed but did not yet name a released version. Preventing privilege escalation requires checking the process that Linux actually runs. When checkpoint restore is available, Linux capabilities must be verified at the destination instead of trusted simply because the configuration asked for fewer privileges. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading What Is Kubernetes Security? A Linux Admin’s Practical Guide Securing Kubernetes and Cloud-Native Environments through DevSecOps How to Check Docker Container Isolation in Linux Kata Containers Flaw Weakens Container Security With Host-Chosen Mounts Understanding Linux Privilege Escalation Patterns and Security Measures . A checkpoint restore can reintroduce Linux capabilities, the smaller permissions that divide up root. privilege, escalation, container, always, begin, exploit, checkpoint, restore__EOC__. Dave Wreski
Linux containers can be paused, checkpointed, and rebuilt later with CRIU. . That sounds like saving application memory, but a useful checkpoint must carry much more than data pages. It records enough of a process's execution state for Linux to continue it. That includes identity and privilege, open resources, namespaces that isolate what the process can see, and syscall filters that limit its requests to the kernel. Recent container runtime disclosures make this distinction practical. If a destination trusts checkpoint state more than its own policy, a restored workload can return with privileges administrators believed they had removed. A Checkpoint Is a Map of a Running Process CRIU stands for Checkpoint/Restore In Userspace. It can freeze an application, write its state into image files, and reconstruct the process later. To do that, CRIU must capture relationships that ordinary file backups ignore. A running application may depend on mapped memory, open files and network connections, child processes, pending signals, isolation boundaries called namespaces, and identifiers managed by the kernel. The checkpoint is therefore a description of a live execution environment. Restoring it asks the host to create processes and reconnect those relationships closely enough that the application can continue. Figure 1. CRIU’s official memory workflow shows how dump data moves through page transfer and restore stages. Source: CRIU project . That is useful for migration and recovery, but it also raises the trust level of the checkpoint. A manipulated archive may influence how the restored process is built. Which Security Properties Travel With the Process Linux decides what a process may do through several layers. User and group IDs establish identity. Capabilities divide traditional root privilege into narrower powers such as changing ownership, administering networks, or bypassing file permission checks. The no_new_privs setting prevents an executed program from gainingprivileges it did not already have. Seccomp filters restrict which system calls the process may make. Namespaces decide which view of processes, mounts, networks, users, and other resources the process receives. These controls are related, but they are not interchangeable. A process with a restrictive seccomp filter may still hold dangerous capabilities. A process in a user namespace may map identities differently from the destination host. A faithful restore needs to preserve enough state for the application to work. A secure restore also needs to prove that preserved state is allowed at the destination. Why Destination Policy Can Lose the Argument Container platforms normally describe desired security settings in configuration. The runtime uses those settings when it starts a new Linux process. Restore begins from a different position. The checkpoint already describes the process that existed before it arrived. If the runtime applies that record directly, saved credentials or filters may take precedence over the new specification. CVE-2026-92574 documented this problem in CRI-O. The disclosure says a malicious checkpoint could retain credentials, Linux capabilities, no_new_privs , and seccomp state instead of enforcing the destination Kubernetes security context. A containerd advisory published earlier in September described a comparable outcome. The project disabled one restore path by default because it could not guarantee that destination policy would be enforced. Neither case makes CRIU inherently unsafe. They show that the caller must decide which saved attributes are authoritative and reject restores that cannot satisfy destination rules. What to Verify Before Using CRIU in Production Begin with the purpose. A forensic checkpoint kept for investigation may not need to be restored into a normal production cluster. A migration feature has a different risk than a local developer workflow. Control who can create, upload, and restore checkpoint images. These actionsshould require stronger permission than pulling and starting an ordinary container image. Keep checkpoints in trusted storage and record where they were created. Provenance matters because the source environment may have allowed identities or capabilities that the destination forbids. Document which attributes the runtime restores and which it rebuilds. Do not assume a Kubernetes security context automatically replaces every saved value. After restoration, compare effective state with policy. Check the running process's user and group IDs, capability sets, namespace placement, no_new_privs status, and seccomp mode. Finally, follow the security guidance for the exact runtime and version in use. CRIU provides the restoration mechanism, while CRI-O, containerd, Kubernetes, and vendor integrations decide how it is exposed. Linux containers make application movement look simple, but CRIU shows why it is not. A checkpoint carries an execution identity, and that identity needs the same provenance, authorization, and destination validation expected of any other security-sensitive artifact. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading What Is Kubernetes Security? A Linux Admin’s Practical Guide Securing Kubernetes and Cloud-Native Environments through DevSecOps How to Check Docker Container Isolation in Linux Kata Containers Flaw Weakens Container Security With Host-Chosen Mounts Fedora 42: checkpointctl 1.4.1 Critical CVE-2025-47906 Security Patch . Discover CRIU's impact on Linux container checkpointing and how it influences security practices for restoring app states. CRIU, Linux Containers, Checkpointing, Application Migration, Security Practices__EOC__. Andrew Kowal
A container normally starts under the security rules of the system receiving it. . A checkpoint restore changes that sequence because the workload arrives as a saved snapshot with part of its Linux process state already recorded. Two recent disclosures from containerd and CRI-O, the software that starts containers for Kubernetes, show the consequence. A restore could preserve account identity, Linux privileges, the no_new_privs safeguard, and seccomp syscall filters that did not match the new configuration. The failure occurs at the moment of restore: imported process state crosses into a new environment before the destination has proved that it matches local rules. That makes restore its own container security boundary, not merely another way to start a workload. A Checkpoint Carries Security State With the Workload A container checkpoint captures enough information for CRIU to reconstruct a stopped process later. That can support debugging, recovery, migration, and forensic work. The archive must preserve more than memory pages. It may contain process identifiers, open resources, user and group information, capability sets, and other state the kernel uses to decide what a process can do. That makes a checkpoint different from an ordinary application backup. Restoring it asks the destination host to rebuild an execution identity, not merely copy files. A safe restore process therefore has to answer a difficult question: should security state come from the checkpoint, the destination configuration, or a verified combination of both? CRI-O and containerd Reached the Same Failure Mode The containerd project disclosed in September that its CRI implementation could restore an untrusted checkpoint through CreateContainer while bypassing the destination security context. The project fixed supported branches by disabling that restore path by default in versions 2.2.7 and 2.3.4. containerd 2.4.0 removed the feature. Administrators who turn the experimental path back on remainexposed because the runtime cannot guarantee enforcement of destination policy during that restore. Figure 1. Container restore introduces two possible sources of security state, and the runtime must reconcile them before the process starts. Original LinuxSecurity diagram. Later, CVE-2026-92574 documented a comparable problem in CRI-O. A user able to create a pod from a malicious checkpoint could cause restored process security state to take precedence over the settings requested for the destination pod. The details and remediation differ, but the pattern is the same. Both runtimes encountered a point where imported Linux state could cross a policy boundary without being fully rebuilt or rejected. Why Configuration Can Disagree With the Running Process Orchestrators reason about declared configuration. The Linux kernel acts on the credentials and filters attached to the running process. During a normal container start, the runtime creates a new process and applies the requested restrictions. During restore, CRIU reconstructs a process that already had an identity when it was frozen. If the runtime reports the requested configuration while the kernel has restored different state, dashboards and policy records can look correct. That does not prove the process is running with the intended restrictions. The containerd advisory explicitly warned that status reporting could reflect the requested configuration rather than the restored state. The CRI-O disclosure likewise centers on saved state overriding destination policy. This mismatch is especially important for automated compliance checks. A control that reads only the pod specification may confirm intent without validating enforcement. How Operators Can Make Restore Safer Start by treating restore as a privileged cluster capability. Limit who can create workloads from checkpoints and separate that permission from ordinary pod creation. Accept checkpoint images only from controlled registries. Protect the system thatcreates them, require review of their origin, and prevent users from attaching checkpoint metadata to arbitrary images. Use admission controls to reject checkpoint-based creation unless a namespace or workload has an explicit business need. Restore should be the exception, not an invisible variation of a normal deployment. Follow runtime-specific remediation. For containerd, update to a patched branch and avoid re-enabling experimental restore through CreateContainer. For CRI-O, track the fixed supported release because the initial advisory said branch fixes existed but had not yet shipped. After restoring any sensitive workload, verify effective process identity and restrictions at the destination. Configuration review remains useful, but it should be paired with runtime and host-level evidence. The broader container security lesson is operational. A checkpoint is not safe simply because it came from a container. It must be authenticated, authorized, and revalidated against destination policy before the Linux process can continue. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading Understanding Container Security Best Practices for Linux Admins Confidential Containers Need a Boundary the Linux Host Cannot Cross Docker Sandboxes Flaw Lets a Guest Reach Host Unix Sockets Securing Kubernetes and Cloud-Native Environments through DevSecOps Effective Linux Software Supply Chain Security Workflows Explained . Container security requires careful handling of restore scenarios to prevent unauthorized access and policy violations.. Container Security, Linux Checkpoints, Process Identity__EOC__. Andrew Kowal
Kubernetes groups one or more containers into a pod, the basic unit it deploys. . CRI-O is the container runtime that starts those workloads on Linux. CVE-2026-92574 shows that a checkpoint, or saved snapshot of a running process, can carry older privileges into a new pod. The flaw affects users who can create a pod from checkpoint files. A malicious checkpoint can preserve account identity, privileges, and other restrictions enforced by the Linux kernel, even when they conflict with the security rules requested for the destination pod. No active exploitation has been confirmed. The immediate concern is narrower: clusters that permit checkpoint-based restore may trust policy declarations that do not describe the process actually running. What CVE-2026-92574 Changes During Restore A checkpoint is more than a saved copy of application memory. CRIU records enough process state to rebuild a running workload, including details tied to identity and privilege. The published advisory says CRI-O can restore credentials, Linux capabilities, no_new_privs, and seccomp state from checkpoint data. Those values may take effect instead of the settings requested for the destination pod. Figure 1. A CRI checkpoint request moves through the kubelet, CRI-O, runc, and the Linux kernel. Source: SANE Lab . That creates a policy gap. Kubernetes may ask for a restricted process, while the restored Linux process keeps security attributes from the system where the checkpoint was created. The checkpoint therefore becomes security-sensitive input. Treating it like an ordinary container image misses the part of the archive that can influence how the kernel constrains the restored process. Why the Destination Pod Can Look Safer Than It Is A pod specification expresses the security context an operator wants. The kernel enforces the state the runtime actually creates. Normally, the runtime translates the requested settings into user IDs, capability sets, privilege restrictions, and syscall filters.Restore changes that sequence because process state already exists inside the checkpoint. If CRI-O accepts that saved state without proving it matches destination policy, the declaration and the running process can diverge. An admission check may approve a restrictive configuration even though the restored workload retains a broader privilege set. This is why reviewing YAML alone is not enough for a restored container. Operators need assurance that the runtime rebuilt security state from destination policy or rejected a checkpoint that could not be reconciled safely. Which CRI-O Environments Are Exposed The advisory lists supported CRI-O versions 1.34 and later as affected. Red Hat says OpenShift Container Platform is affected from version 4.17 onward. Exploitation is not available to every ordinary workload. An attacker needs permission to create a pod from a malicious checkpoint image, and the checkpoint restore feature must be available. Those prerequisites should shape prioritization. Clusters that do not use checkpoint restore have a different risk profile from environments that use it for recovery, migration, debugging, or operational experiments. The advisory also says fixes were applied to supported branches but were not yet released when the record became public. Administrators should follow their CRI-O or OpenShift vendor channel for a fixed build instead of assuming a particular version is safe. What Kubernetes Administrators Should Do Now First, determine whether checkpoint restore is enabled or used anywhere in the cluster. Include development and recovery environments, where experimental runtime features may be more common. Next, audit who can create pods from checkpoint images. Restrict that permission to trusted administrators and automation. A user who can submit an ordinary pod should not automatically gain authority to restore opaque process state. Treat checkpoint images as privileged artifacts. Limit accepted registries, protect the build and storage path,and reject untrusted checkpoint annotations through admission policy where possible. For any workload restored from an untrusted or poorly controlled checkpoint, stop it and recreate it from a normal image. A fresh start lets the runtime build process security state from the destination configuration. Finally, verify the vendor fix once released. Confirm the package version, restart affected runtime components as directed, and test that a restored workload cannot retain credentials or capabilities that the target policy removes. CVE-2026-92574 does not mean every CRI-O cluster is exposed. It shows why Kubernetes security cannot rely on requested policy alone when a checkpoint can reintroduce older Linux process state. Restore permissions, artifact trust, and runtime verification must be treated as one control set. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading What Is Kubernetes Security? A Linux Admin’s Practical Guide Securing Kubernetes and Cloud-Native Environments through DevSecOps How to Check Docker Container Isolation in Linux Kata Containers Flaw Weakens Container Security With Host-Chosen Mounts Fedora 41: cri-o 1.34.2 Critical Runtime Security Updates 2025-8bd0d993db . Kubernetes admins need to mitigate privilege escalation risks linked to CRI-O checkpoint restores for environment security. Kubernetes Security Policies, CRI-O Checkpoint Flaw, Container Runtime Security, Privilege Escalation, Linux Administration__EOC__. Andrew Kowal
CISA has added CVE-2025-39964, a flaw in the Linux kernel’s built-in cryptography interface, to its list of vulnerabilities being used in real attacks. . The designation raises the urgency for Linux teams even though public sources describe only a limited availability impact. What remains unclear is how attackers are using the flaw. CISA has not disclosed the targets, required configuration, or result of the attacks, so the evidence supports urgent patching but not claims of root access or data theft. What Changed on September 18 CISA’s notice confirms that CVE-2025-39964 has been exploited in the wild. That changes patch priority even though the underlying bug and fix are older. CISA added CVE-2025-39964 to the KEV Catalog based on evidence of active exploitation. Source: CISA. A KEV addition does not automatically reveal the incident behind it. The notice does not name an attacker, victim population, targeted distribution, required configuration, or exploit chain. It also does not state that the bug produced root access, code execution, or a container escape. What the Linux Crypto Interface Does AF_ALG is a Linux interface that lets applications ask the kernel to encrypt data, calculate hashes, and perform other cryptographic work. Programs send those requests through a socket, much like they would send network data. The kernel must keep track of which data belongs to each request. If two parts of a program write to the same socket at the same time, their data can become mixed and the kernel can lose track of the operation’s state. How Two Requests Could Disrupt One Operation The kernel advisory says simultaneous writes to one AF_ALG socket are invalid because their data can be interleaved unpredictably. More importantly, concurrent writes may make the socket’s internal state inconsistent. The stable fix makes the rule explicit: only one writer can use the socket at a time. A second writer must wait instead of interfering with an operation alreadyin progress. The advisory assigns low availability impact and no confidentiality or integrity impact. That describes the documented bug assessment. It does not tell us how CISA’s observed exploitation worked, and it should not be silently upgraded into a privilege-escalation claim. Why an Older Low-Impact Bug Now Matters A severity score describes the technical impact known when the vulnerability was assessed. It does not show whether attackers are using the flaw. CISA’s update adds that missing fact: exploitation has now been observed outside a laboratory. That does not invalidate the advisory’s low documented impact. It means Linux teams should not treat the score as the only scheduling signal. A fix that previously waited behind broader maintenance may now deserve an accelerated window, while analysts continue looking for authoritative details about the actual campaign. What Linux Teams Should Do Start with the vendor kernel package. Distribution kernels often backport a fix without changing to the upstream release where it first appeared. Check whether the running build contains the AF_ALG concurrent-write repair for CVE-2025-39964. Prioritize systems where untrusted or lower-privileged software can reach AF_ALG . That inventory improves triage, but it does not prove exploitability. The primary sources do not publish the exact conditions used in the attacks CISA observed. After installing a fixed kernel, complete the required reboot or approved live-patch workflow and verify the running version. Kernel patching is unfinished until the active code has changed. What Linux Teams Can Say with Confidence CVE-2025-39964 shows why fresh exploitation evidence can matter more than an old severity label. A race documented as inconsistent state and low availability impact is now on CISA’s exploited list. The correct response is prompt verification and patching, paired with disciplined language. Active exploitation is confirmed. The public sources do not yet establish whois attacking, which AF_ALG use is exposed, or what outcome the exploit produced. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading Linux Could Soon Disable Vulnerabilities Without a Reboot: Kernel Killswitch Copy Fail: A Linux Kernel Bug That Can Turn Four Bytes Into Root Linux Kernel Vulnerabilities Exploited in 2025: CISA KEV Insights From Dirty COW to DirtyDecrypt: Why Linux Keeps Rediscovering Memory Ownership Bugs . CISA warns of active exploitation of a Linux kernel flaw impacting cryptography, calling for immediate patching actions. Linux Kernel, CISA Advisory, Cryptography Flaw, Active Exploitation, Security Alert__EOC__. MaK Ulac
Security researchers have shown how hidden instructions in an AWS AgentCore support ticket could push an AI agent into running commands as root and exposing a service credential. . The test connected a familiar AI weakness, prompt injection, to the permissions of the Linux environment behind the agent. This was a controlled demonstration, not a known attack. AWS classified the report as informative, but the result shows why teams should treat an AI agent’s shell access, service credentials, and network access as one connected security boundary. How a Hidden Instruction Reached a Root Shell The Unit 42 research placed a hidden instruction in a support ticket. When the agent processed that untrusted content, the instruction told it to download and execute a reconnaissance script through the built-in shell tool. The command shell ran as root inside the test environment. It also used the same Linux identity as the main AgentCore service, which meant the shell could reach information belonging to that service. Prompt injection supplied the decision. The shell supplied the operating-system authority. Once the model called the tool, the command inherited what that tool could reach. How Process Memory Exposed the Credential Linux exposes information about running programs through the /proc filesystem. When permissions allow it, one process can use files there to see how another process uses memory and even read that memory directly. In the test, the root shell and the main service shared the same identity. Researchers searched the service’s readable memory and found both a login token and the server address needed to reuse it. The credential vault still protected the token at rest and in transit. The gap appeared when the harness resolved that token into plaintext for actual use. A credential cannot remain encrypted while software presents it to a downstream service, so in-use memory becomes a separate security boundary. What AWS Says About the Default Tools AWS documentation says AgentCore sessions can use shell and file tools unless administrators restrict them with the allowedTools setting. If that setting is left out, the agent can use every available tool. AWS also states that allowedTools controls which tools the model can select during InvokeHarness. A separate command-execution API has its own IAM permission. Teams therefore need both tool scoping and IAM review; narrowing model-visible tools does not replace control of direct runtime commands. Unit 42 says AWS closed the report as informative and pointed to tool scoping and egress filtering as customer controls. That status matters: the findings demonstrate a configuration risk and privilege boundary, not an AWS-confirmed product vulnerability. Unit 42’s diagram shows the permission gap between invoking AgentCore and the broader authority of the harness execution role. Source: Unit 42. How Teams Can Limit What Agents Can Do Give each AgentCore session only the tools it needs. If an agent does not require a command shell or permission to change files, remove those capabilities. Teams should also review AWS identity permissions so direct command execution is not granted by default. Network egress should also be narrow. The demonstration depended on downloading code and replaying a credential against an external service. Restricting destinations does not cure prompt injection, but it can reduce what a successful injection can retrieve or reach. Credentials assigned to the harness should carry the least downstream authority possible. The stolen token in the test belonged to the operator’s service account, not the invoking user. One user’s ability to ask the agent for help should not silently become the harness’s ability to reach every connected service. The AI Model Is Only One Part of the Risk The demonstration worked because several controls failed together. A hidden instruction reached a powerful shell; that shell could read the service’s memory, the memory contained a usablecredential, and the environment could connect to the outside service. For AWS AgentCore teams, the practical lesson is to bound the shell, filesystem, IAM role, credential scope, process visibility, and network path independently. A model cannot reliably decide whether every instruction is trustworthy. The runtime must limit what an untrusted instruction can make real. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading Linux Logs Prompt AI Misclassification Risks and Security Gaps Linux IAM Misconfigurations Raise Cloud Security Concerns AI Agents and Their Impact on Linux Security Threat Models AI Impacts Linux Security Operations: Addressing New Risks . Learn how prompt injection can expose AWS AgentCore credentials, highlighting key security practices to mitigate risks.. AWS AgentCore, Linux security, credential exposure, prompt injection, cybersecurity best practices__EOC__. MaK Ulac
Get the latest Linux and open source security news straight to your inbox.