PwnEscape Firecracker: thoát VM lên thẳng host root, và cái bẫy ‘không bật jailer’

Ngày 06/11/2026, nhóm pwn.ai công bố Part 2 của PwnEscape Firecracker, một demo cho thấy một VM Firecracker đã thoát ra ngoài và khiến Firecracker trên host chạy một lệnh do guest chọn, lên tới quyền root. Tin này có thật không, nghiêm trọng tới mức nào, và anh em có phải làm gì ngay hôm nay hay không, mình sẽ gỡ từng lớp trong bài này, bắt đầu từ cái bẫy nằm ngay trong cấu hình demo.

Cái bẫy nằm ngay ở cấu hình demo, pwn.ai ghi rõ demo chạy Firecracker trực tiếp với quyền root dưới systemd-run, không có jailer, trong khi containment production gồm hạ đặc quyền, namespace và seccomp cần đánh giá riêng. Audit độc lập kết luận chuỗi thoát cần hai lỗi chồng lên nhau, host kernel chưa vá và Firecracker chạy không có jailer, chỉ một trong hai thôi cũng chặn chuỗi này. Part 2 chỉ trình diễn CVE-2026-99999 trên một cấu hình Firecracker, chứ không công bố CVE mới nào.

Chuỗi 5 hop PwnEscape Firecracker đưa guest lên thẳng host root

Chuỗi này dùng một lỗi đã biết để đi từ một packet mạng trong guest tới một lệnh chạy bằng đặc quyền của Firecracker trên host. Mình đọc Part 2 thì thấy mỗi mắt xích đều có số liệu chạy thật để anh em kiểm chứng, trừ tiền đề cấu hình ở cuối.

Bằng chứng chạy thật là marker N8V23M2 cộng một ký tự xuống dòng, tổng cộng 8 byte, xuất hiện đúng một lần trên stderr của Firecracker. Process Firecracker mang PID 2936 vẫn còn sống, guest vẫn trả lời SSH và uptime lúc đó là 1615.72 giây. Cấu hình demo là Firecracker v1.16.1, host kernel 7.0.0-1011-aws, chưa kiểm chứng độc lập, guest kernel 6.18.44 trở lên, chạy trực tiếp với quyền root dưới systemd-run và ghim bằng taskset, không có jailer.

Primitive đọc bộ nhớ host từ Part 1 và nonce tìm trang guest qua EPT

Mình thú thật là đoạn EPT này làm mình vọc hơi lâu mới theo kịp, vì nó nghe như phép thuật, cơ mà bản chất thì hình như khá đời thường. Guest đặt nonce, một giá trị đánh dấu riêng, vào một trang bộ nhớ guest, rồi resolver quét các dải bộ nhớ host mà primitive từ Part 1 bao phủ để tìm ứng viên EPT root. Anh em cứ hình dung là tìm một trang giấy có đánh dấu giữa cả kho giấy của host, tìm rộng cho ra hai ứng viên rồi rút xuống còn một, với guest_gpa 0x08f03000 và guest_page_hpa 0x165610000. EPT là bảng trang mở rộng của CPU, dịch địa chỉ guest sang địa chỉ vật lý thật trên host.

Tìm ra PGD host rồi lật ASLR để thấy Firecracker đang chạy ở đâu

Từ trang guest đó, mình thấy reverse mapper làm tiếp khá gọn, anh em để ý nhé, nó tìm trong bảng trang host một mapping trỏ tới guest_page_hpa đã biết, rồi khôi phục địa chỉ ảo và root bảng trang đi kèm. Mapper kiểm tra hai chiều bằng cách walk lại bảng trang, tới khi chỉ còn một address space đã kiểm chứng, và giữ root của nó làm host_pgd 0x14afc2000. Image mapper nhận diện image ELF của Firecracker nhờ dãy byte đã biết trong wrapper write(2), rồi tính load bias dưới ASLR, trả về firecracker_base 0x7298c2400000.

Sửa frame pt_regs trong KVM_RUN rồi ghi một byte serial để Firecracker tự in marker N8V23M2

Anh em để ý chỗ này, frame finder tìm frame pt_regs của thread vCPU đang ở trong KVM_RUN, dùng địa chỉ quay về của ioctl làm manh mối chính. Ứng viên phải thỏa cùng lúc nhiều kiểm tra về syscall, request KVM_RUN, file descriptor và các con trỏ. Thread vCPU gọi self.kvm_vcpu.fd.run, chính là ioctl KVM_RUN. Payload bắt Firecracker gọi write(2, marker, 8) ra stderr, 3 stack word được lưu trước khi sửa, dãy quay về xóa giá trị trả về từ 8 về 0 bằng xor eax,eax; ret, rồi đưa thực thi về điểm tiếp nối ioctl gốc. Trigger là guest ghi một byte vào serial port, sau trigger helper khôi phục cả ba stack word, với frame_hpa 0x13a5bff48.

tìm EPT root bằng nonce
tìm PGD host bằng reverse mapping
tìm base Firecracker, vượt ASLR
tìm frame pt_regs của thread vCPU ở KVM_RUN
sửa frame, bắt Firecracker ghi marker ra stderr
guest ghi một byte vào serial port
khôi phục stack, kiểm tra lại

CVE-2026-99999 đổi byte 0x45 thành 0x4f rồi rò 32 byte bộ nhớ host ra ngoài

Con số 32 byte nghe nhỏ tới mức dễ bị bỏ qua, nhưng chừng nào guest còn gửi packet thì 32 byte đó còn rò ra đấy. Nó là cái primitive nuôi sống toàn bộ chuỗi 5 hop ở mục trên, nên anh em đáng bỏ vài phút hiểu cho đúng cơ chế này. CVE-2026-99999 được Linux kernel CNA công bố ngày 15/10/2026 lúc 12:19 UTC, lỗi có từ kernel 2.6.27, cho guest rò 32 byte bộ nhớ host mỗi lần gửi packet.

CHECKSUM_PARTIAL và lỗi check-then-change trong IPv4 stack của kernel host

CHECKSUM_PARTIAL là một lời hứa ghi sau, khi csum_start và csum_offset ủy quyền cho một lần ghi sau đó vào bộ nhớ packet. Mình hay hình dung lỗi check-then-change này như một bưu kiện đã kiểm tra xong rồi mới bị tráo trước khi niêm phong, kiểm tra thì đúng, hàng gửi đi thì đã khác, và anh em cứ nhớ hình ảnh đó là nắm được nửa cơ chế. Cụ thể, ip_do_fragment hoàn thành checksum trước khi lấy con trỏ IPv4 header, nên lần ghi muộn đó chồng lên chính header vừa kiểm tra. Đây là lỗi check-then-change theo nghĩa ngữ nghĩa, chứ không dính race giữa các thread.

IHL nhảy từ 5 lên 15 và fragmenter copy 60 byte khi skb_headlen chỉ có 28

Byte đầu tiên của header đổi từ 0x45 sang 0x4f, tức là IHL nhảy từ 5 lên 15, mà IHL là độ dài header IPv4 tính theo đơn vị 4 byte. Con số 32 byte này nhỏ mà ngốn, vì header được hiểu là dài 60 byte thay vì 20 byte, trong khi skb_headlen chỉ có 28 byte. Lần copy sau đó là 60 byte, chênh lệch 32 byte phát ra ngoài dưới dạng IP option, anh em để ý là chênh lệch này lặp lại được mỗi lần guest gửi packet.

Fix commit 6785011f8b16 chặn checksum ghi vào header nhưng validation đầu vào vẫn chưa đủ

Fix commit 6785011f8b16, do Michael S. Tsirkin của Red Hat viết, gồm 44 dòng thêm và 12 dòng xóa trên 6 file, đặt một guard chặn checksum ghi vào header IPv4. Guard trong commit này đặt khá gọn, cơ mà anh em nhớ là tác giả fix và pwn.ai đều nói validation đầu vào hoàn chỉnh vẫn cần thêm việc, và fix này là defense in depth chứ chưa chạm tới root cause. Vá kernel trước đã, tính sau. Vì vậy bump kernel là bước bắt buộc, operator vẫn cần theo dõi các bản vá tiếp theo ở phía input.

Lỗi nằm trong kernel host, Firecracker và KVM chỉ là ranh giới bị vượt

Tên gọi mới là chỗ dễ nhầm nhất, anh em ạ, vì lỗi nằm trong IPv4 networking stack của host kernel, còn tên KVM escape và Firecracker chỉ gọi tên ranh giới đã bị vượt qua. Nhầm chỗ này thì vá sai chỗ.

Tên gọi KVM escape mô tả ranh giới bị vượt chứ không chỉ file chứa lỗi

Tranh luận trên daily.dev và Steinslab Daily tập trung đúng vào điểm này, và Steinslab Daily nhấn mạnh chuỗi thoát chỉ hợp lệ khi jailer tắt. Tranh luận này có lý đấy, vì nó tách rõ tên gọi khỏi vị trí file chứa lỗi, và anh em cứ tách hai thứ này ra là khỏi nhầm sau này.

Đổi Firecracker sang gVisor hay Nova Microhypervisor có hết lỗi kernel này không

Cả hai ý này đều có lý, cơ mà anh em đừng vội đổi mô hình chỉ vì nghe tên mới hay hơn. clhodapp hỏi có nên nghiêng về patchable software isolation như gVisor nhiều hơn khi hardware isolation của microVM sụp đổ trước agent hay không, còn lrvick thì nói ngày càng tin Nova Microhypervisor với microkernel nhỏ, đã qua kiểm chứng hình thức, là hướng đúng. Đổi sang mô hình cách ly khác không tự động hết lỗi này, vì nhiều mô hình đều dùng chung lớp kernel networking, và lỗi này nằm trong Linux networking stack chứ không nằm trong KVM core. Nova là góc nhìn dài hạn, chưa phải giải pháp vá ngay hôm nay. bulk88 nói, với claim chưa kiểm chứng, rằng làm exploit này trong 2 tới 3 phút dùng GDB, nhưng comment đó bỏ qua primitive bộ nhớ host từ Part 1.

AWS EC2 Lambda Fargate không bị ảnh hưởng theo bulletin 2026-137-AWS

Các dịch vụ quản lý EC2, Lambda và Fargate không bị ảnh hưởng theo AWS bulletin 2026-137-AWS, công bố ngày 15/10/2026 lúc 10:30 AM PDT, mô tả issue trong Linux kernel virtio-net và TAP networking path. Mình đọc bulletin này thì thở phào, anh em nào chạy dịch vụ quản lý thì không phải vá host. Bulletin ảnh hưởng tới KVM-based hypervisor chạy kernel Linux chưa vá trong phạm vi bulletin của AWS là version 4.4 tới 6.18. Dải 4.4 tới 6.18 là phạm vi bulletin của AWS, khác dải từ 2.6.27 của CVE record.

Điểm 9.3 của CVE record và điểm 8.8 của Red Hat lệch nhau vì một chữ PR

Hai con số 9.3 và 8.8 chỉ lệch nhau một metric, nhưng hình như đằng sau nó là hai cách đọc khác nhau về cùng tập bằng chứng. Một bên gộp ba kết quả demo thành một vector, một bên tách rõ tầng production với tầng lab.

Vector PR-N của CVE record và vector PR-L của Red Hat khác nhau đúng một metric

Mình so hai vector này thì thấy chỉ lệch đúng một chữ PR, anh em để ý nhé, CVE record chấm CVSS 3.1 9.3 CRITICAL với vector AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, còn Red Hat chấm 8.8 IMPORTANT với vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, chỉ khác đúng một metric PR. CVE record chấm 9.3 vì mô tả host root và continuous leak, Red Hat chấm 8.8 vì giả định attacker cần một ít đặc quyền trong guest. CISA chưa thêm CVE này vào KEV, EPSS dưới 1%.

Rò rỉ bộ nhớ demo trên production Vercel còn crash và code execution chỉ demo trên máy lab

Rò rỉ bộ nhớ demo trên production của Vercel, còn crash và code execution chỉ demo trên máy lab của nghiên cứu viên, không report nào cho thấy truy cập file khách hàng, secret hay dữ liệu ứng dụng. Mình thấy đoạn này dễ thổi phồng nhất, anh em gộp ba kết quả demo thành một câu là sai ngay, trong khi Trail of Bits sau 4 engineer-week với 20 finding đã kết luận virtualization boundary của Vercel là sound về kiến trúc. Đó là gốc của khoảng lệch 9.3 với 8.8, vì CVE record gộp ba kết quả demo thành một vector, còn nghiên cứu viên tách rõ tầng production với tầng lab.

Nghiên cứu viên chỉ lượng hóa leak 32 byte và nói rõ không claim root ở production của vendor

Writeup của nghiên cứu viên chỉ lượng hóa leak ở 32 byte cho mỗi active case và nói rõ không claim root ở production của vendor, với câu gốc là ‘it is not a claim of root command execution in any vendor’s production environment’. Mình giữ câu này trong đầu khi đọc điểm 9.3, anh em quên nó là tưởng mọi triển khai đều mất root ngay. Fix chỉ là guard tại điểm hoàn thành checksum, chưa sửa đường đi để metadata sai dạng lọt vào, nên điểm số cao không có nghĩa mọi triển khai đều đã mất root.

Vercel challenge 1 triệu USD và 10 giờ reboot toàn fleet của Fly.io

Tin tức bảo mật dừng ở điểm số và cơ chế, nhưng hai con số đáng tiền nhất tuần này lại nằm ở phía vận hành. Một bên là 1.285 report đổ về trong hai tuần, một bên là 10 giờ reboot của một nhà cung cấp thật.

Một finding Critical giữa 1.285 report đổ về challenge của Vercel

Challenge 1 triệu USD tổng prize pool mở ngày 18/08/2026, chạy hai tuần tới 01/09/2026, nhận 1.285 report và trả 242.000 USD bounty. Mình thấy breakdown này đúng kiểu săn bug thời AI, anh em nhìn là thấy, trong đó có 57 report hợp lệ, 877 report trùng lặp, 319 report không áp dụng, 32 report informative và 1 finding Critical. Report đầu tiên tới Vercel ngày 20/08 từ Paulos Yibelo của pwn.ai, rồi report riêng tới kernel security contact ngày 04/09, fix vào networking tree ngày 08/10, merge mainline ngày 14/10, CVE công bố ngày 15/10. Nghiên cứu dùng GPT-5.6 Sol, tìm ra lỗi trong 3 ngày, chi phí dưới 700 USD tiền token, theo claim của pwn.ai, chưa kiểm chứng độc lập.

Mốc 50.000 USD cho một report chỉ là báo cáo thứ cấp chưa kiểm chứng trực tiếp

Mức payout tối đa cho một report được các nguồn thứ cấp báo cáo là 50.000 USD, dựa trên Cyber Security News và Webhosting.today, chưa kiểm chứng trực tiếp. Mình tạm ghi con số này vào diện nghe cho biết thôi, anh em đừng ghi nó như fact chính thức. markasoftware nói đây là mô tả cách khai thác lỗ hổng PwnEscape trong thực tế trên Firecracker VM, đã disclose nhiều tuần trước. scoodah ước gì bài viết nói rõ hơn về cấu hình không jailer.

Fly.io reboot 10 giờ, region iad 17 wave và lời khuyên rotate credential từ 15 tới 17/10

Fly.io nghe về CVE tối 15/10, patch và reboot toàn bộ fleet trong 10 giờ ngày 16/10/2026, region lớn nhất iad cần 17 wave, cuối ngày không Fly Machine hay dữ liệu khách hàng nào bị mất. 10 giờ reboot là con số ngốn sức thật, anh em hình dung cả fleet reboot liên tục là hiểu hôm đó căng tới mức nào. Giữa sự cố, một chassis bốn node ở gru mất nguồn, machine trên các host đó down tới khi khôi phục ngày 20/10. Fly.io khuyên rotate credential gửi qua HTTP hoặc giao thức không mã hóa từ 15 tới 17/10, kể cả traffic không mã hóa qua 6PN, vì exploit khó phát hiện, và họ không có bằng chứng dữ liệu khách hàng bị lộ. Post-mortem ngày 06/11/2026 của Daniel Botha chốt bằng lời khuyên mã hóa traffic giữa các service.

Checklist hôm nay cho người chạy Firecracker và KVM tự quản

Tới đây thì câu chuyện không còn là tin tức nữa mà là việc phải làm trước khi đi ngủ, và mình gom checklist dưới đây chỉ từ fact đã có, chia rõ người tự quản host với người dùng nền tảng quản lý.

Vá kernel host lên 5.10.272, 6.1.190, 6.6.159 và các bản fix rồi reboot

Các bản kernel đã fix gồm 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11, cộng 7.3-rc7 trên mainline. Mình vá host trước đã, anh em nhớ, vá lên bản fix hoặc build của vendor rồi reboot vào kernel đã vá, vì chỉ cập nhật kernel guest không fix host. Anh em kiểm tra advisory của vendor tính tới 07/11/2026 và xác nhận fix có trong kernel đang chạy, vì distribution thường backport fix mà không đổi số version.

Bật jailer Firecracker, giữ seccomp mặc định và tắt nested virtualization

Jailer là binary dựng ranh giới bảo mật trước khi chạy Firecracker, nó chạy với đặc quyền cao để dựng cách ly rồi hạ đặc quyền hoàn toàn, gồm chroot và pivot_root, mount namespace mới, cgroup, rồi drop root sang UID và GID cụ thể. Làm theo ngay, anh em bật jailer, giữ seccomp mặc định, đừng dùng flag no-seccomp, và tắt nested virtualization. Mình tạm thêm hai việc nữa, anh em làm luôn cho đủ bộ.

Mã hóa traffic giữa các service, kể cả trên mạng riêng.

Luyện tập rotate credential trước khi sự cố thật xảy ra.

Người dùng nền tảng quản lý đọc thông báo provider vì provider sở hữu host kernel

Nhóm này không có việc để vá, vì nếu dùng nền tảng quản lý, cloud VM, serverless hoặc sandbox host, provider sở hữu host kernel. Nhóm này nhẹ việc nhất đấy, anh em chỉ cần đọc thông báo bảo mật của provider. Nếu chỉ chạy web server và app thông thường không có guest không tin cậy thì rủi ro thấp.

CVE-2026-122192 là CVE khác của Firecracker, fix trong v1.16.2 và v1.17.0

CVE-2026-122192 là một CVE khác hẳn với CVE-2026-99999, tuyệt đối không gộp. Mình nhắc riêng mục này vì anh em rất dễ nhầm hai CVE khi đọc lướt. Bulletin 2026-169-AWS công bố ngày 04/11/2026 lúc 11:30 AM PST, mô tả issue trong Firecracker v0.23.0 tới v1.16.1. Trong một số điều kiện, bộ nhớ host có thể để root user trong guest đọc hoặc sửa bộ nhớ của Firecracker process. V1.16.0 và v1.16.1 bị ảnh hưởng, fix có trong v1.16.2 và v1.17.0, AWS khuyến nghị nâng cấp lên bản đó hoặc mới hơn. Một cái là lỗi kernel IPv4, một cái là lỗi Firecracker.

Chọn nhanh theo nhu cầu chạy Firecracker tự quản hay dùng nền tảng quản lý

Anh em chạy Firecracker và KVM tự quản thì vá kernel host lên bản fix rồi reboot và bật jailer ngay hôm nay. Escape cần hai lỗi chồng lên nhau, host kernel chưa vá và Firecracker chạy không có jailer, chỉ một trong hai thôi cũng chặn chuỗi này. Anh em dùng nền tảng quản lý thì đọc thông báo của provider vì provider sở hữu host kernel. Anh em chỉ chạy web server và app thông thường không có guest không tin cậy thì rủi ro thấp, cứ đưa fix vào chu kỳ patch bình thường. Mình mời anh em chia sẻ trải nghiệm ở dưới, đã vá lên bản kernel nào, đã bật jailer ra sao, provider của anh em nói gì nhỉ.

Nguồn tham khảo

• pwn.ai Part 2, Firecracker VM Escape: https://pwn.ai/blog/firecracker-escape
• pwn.ai Part 1, PwnEscape: https://pwn.ai/blog/pwnescape
• dev.to, Frank Chu, 9.3 to root in 5 hops: https://dev.to/frankchu/93-to-root-in-5-hops-i-audited-the-firecracker-escape-4fhn
• Severity Daily, CVE-2026-99999 PwnEscape 9.3: https://severitydaily.com/linux-kernel-cve-2026-99999-pwnescape-9-3-host-root-researchers-disclaim-red-hat-8-8/
• Fly.io, Well, That Wasn’t Fun: https://fly.io/blog/well-that-wasnt-fun/
• Clydara, PwnEscape Linux Kernel VM Escape: https://www.clydralab.com/blog/pwnescape-linux-kernel-vm-escape
• CVE.org, CVE-2026-99999: https://www.cve.org/CVERecord?id=CVE-2026-99999
• Red Hat, CVE-2026-99999: https://access.redhat.com/security/cve/cve-2026-99999
• AWS, Bulletin 2026-137-AWS: https://aws.amazon.com/security/security-bulletins/2026-137-aws/
• AWS, Bulletin 2026-169-AWS: https://aws.amazon.com/security/security-bulletins/2026-169-aws/
• Rescana, PwnEscape CVE-2026-99999: https://www.rescana.com/post/linux-kernel-pwnescape-cve-2026-99999-guest-to-host-prepare-now
• OpenCVE, CVE-2026-99999: https://app.opencve.io/cve/CVE-2026-99999
• TuxCare, PwnEscape KVM Guest Escape: https://tuxcare.com/blog/pwnescape-kvm-guest-escape/
• Hacker News, thread 50397219: https://hacker-news.firebaseio.com/v0/item/50397219.json
• daily.dev, Firecracker VM Escape discussion: https://daily.dev/posts/firecracker-vm-escape-pwnescape-part-2-sfk93csxv
• Steinslab Daily, Vol 142: https://daily.steinslab.io/en/posts/vol-142-2026-11-07/
• Tech Insider, Vercel KVM Zero-Day VM Escape: https://tech-insider.org/vercel-kvm-zero-day-vm-escape-sandbox-2026/
• CSO Online, KVM Escape attack surface: https://www.csoonline.com/article/4237999/kvm-escape-exposes-broader-attack-surface-in-linux-networking.html
• Firecracker docs, CPU templates and features: https://deepwiki.com/firecracker-microvm/firecracker/6.2-cpu-templates-and-features