CVE-2026-63828

What it actually does

This is a local AppArmor authorization bypass in the Linux kernel. A confined process with an AppArmor profile that permits socket send operations but denies outbound connect operations can use sendmsg() or sendto() with MSG_FASTOPEN to initiate a TCP or MPTCP connection in the SYN packet. Because AppArmor previously checked only the send permission path and did not also mediate the implicit connect performed by TCP Fast Open, the process could establish outbound network connections that a normal connect(2) call would have blocked. The impact is a bypass of intended network egress restrictions for AppArmor-confined workloads, potentially allowing unauthorized outbound communication and data transfer from otherwise restricted processes.

Why it matters to the business

Systems that rely on AppArmor to restrict outbound network access may not enforce those restrictions correctly for affected Linux kernels. A compromised or malicious local process running under a constrained AppArmor profile could make unauthorized outbound connections, enabling command-and-control traffic, data exfiltration, lateral movement support, or policy evasion. The CVSS score is high, but exploitation requires local code execution under a profile with this specific mismatch of allowed send and denied connect permissions. EPSS is currently very low, the issue is not listed in CISA KEV, and no mature public exploitation is indicated, so remediation should be prioritized for hardened Linux fleets, container hosts, multi-tenant systems, and systems that depend on AppArmor for egress control.

How an attack unfolds

An attacker first needs the ability to execute code locally as a process confined by an AppArmor profile. The profile must allow sending on sockets while denying or restricting connect operations to the attacker’s desired destination. Instead of calling connect(2), which AppArmor would deny, the attacker creates a TCP or MPTCP stream socket and uses sendmsg() or sendto() with the MSG_FASTOPEN flag and a destination address. TCP Fast Open combines connection establishment with sending data in the initial SYN, so the kernel performs an implicit connect. On vulnerable kernels, AppArmor checks the send permission but fails to enforce the connect permission for this implicit connection path. If network conditions and TCP Fast Open behavior allow the request, the process can open an outbound connection and transmit data despite the policy’s connect restrictions.

How to fix it

Upgrade to a Linux kernel version that includes the AppArmor fix for mediating implicit TCP Fast Open connects in sendmsg()/sendto() paths. Because no specific downstream package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory when available. Reboot into the updated kernel after installation; patching the package without booting the fixed kernel does not remove exposure. As interim mitigation, review AppArmor profiles for inconsistent network permissions where send is allowed but connect is denied, disable or restrict TCP Fast Open where operationally acceptable, and apply network-layer egress controls such as host firewalls, container network policies, or perimeter filtering to enforce destinations independently of AppArmor.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, contains the fix from the distribution or upstream stable branch. Validate with uname -a and package-manager queries, then compare against the vendor’s fixed kernel advisory. Test AppArmor behavior using a confined profile that allows send but denies connect: a normal connect(2) attempt should be denied, and sendto()/sendmsg() with MSG_FASTOPEN to the same prohibited destination should also be denied after remediation. Also verify TCP Fast Open settings with /proc/sys/net/ipv4/tcp_fastopen and confirm that compensating egress controls block unauthorized destinations regardless of application behavior.

Typical attack path

1. Gain local code execution in a process constrained by an AppArmor profile.
2. Identify that the profile allows socket send operations but denies or limits outbound connect operations.
3. Create a TCP or MPTCP stream socket from the confined process.
4. Call sendmsg() or sendto() with MSG_FASTOPEN and a destination address instead of using connect(2).
5. Use the implicit TCP Fast Open connect path to establish outbound communication that AppArmor policy would have denied for connect(2).
6. Transmit data to an external or otherwise unauthorized endpoint, potentially for exfiltration or command-and-control.

How to detect it

Post-exploitation detection is challenging because the vulnerable path may not generate the AppArmor connect denial that defenders would normally expect. Focus on evidence of unexpected outbound connections from AppArmor-confined processes, especially processes whose profiles are intended to deny network connects. Useful sources include Linux audit logs, AppArmor audit logs, syslog/journald, endpoint telemetry with syscall capture, eBPF network telemetry, host firewall logs, DNS logs, proxy logs, and NetFlow. Look for sendto/sendmsg system calls using the MSG_FASTOPEN flag, outbound TCP or MPTCP connections from confined labels that should not connect externally, and discrepancies where a profile records allowed send behavior but no corresponding allowed connect event. Also review recent process execution, file writes, and network activity for confined services that contacted new, rare, external, or unauthorized destinations.

• MSG_FASTOPEN
• 0x20000000
• sendto
• sendmsg
• apparmor="DENIED"
• operation="connect"
• operation="sendmsg"
• operation="sendto"
• /proc/sys/net/ipv4/tcp_fastopen
• IPPROTO_MPTCP
• SOCK_STREAM

What your security team should do

• Prioritize patching Linux systems where AppArmor is used as a security boundary for containers, sandboxed services, developer workloads, or multi-tenant execution environments.
• Inventory systems with AppArmor enabled and identify kernels that predate the vendor fix for this issue.
• Review AppArmor profiles for network rules that allow send while denying connect, because those profiles are most relevant to this bypass.
• Deploy fixed vendor kernel packages and reboot affected systems into the patched kernel.
• Where rapid patching is not possible, disable or restrict TCP Fast Open if compatible with operational requirements and enforce outbound traffic with host or network firewalls.
• Monitor confined processes for unusual outbound connections, especially connections initiated without prior successful connect(2) activity in audit or syscall telemetry.
• Treat unexpected egress from AppArmor-confined workloads as potentially suspicious and investigate for local compromise or policy bypass attempts.