PHP2Shell: 70% website thế giới vừa phát hiện mình quên khoá cửa suốt 14 năm

Hàng loạt báo lớn như CNN, Fortune, rồi cả CISA (cơ quan an ninh mạng Mỹ) vừa đồng loạt lên bài: khoảng 70% website trên thế giới đang dính một lỗi bảo mật cực nặng, công bố hôm 21/10. Anh em IT khắp nơi mất ngủ tập thể.

Có khi công ty anh chị cũng nằm trong số đó.

Và cái “đứa” tìm ra lỗi này.. là AI.

Mấy hôm nay vài anh chị CEO hỏi mình mà nghe lùng bùng không hiểu gì, nên mình ngồi viết lại một lượt. Hiểu tới đâu giải thích tới đó, kiểu ngồi cafe kể nhau nghe thôi. Cuối bài có checklist chi tiết, anh chị cứ chuyển thẳng cho đội IT hoặc agency làm web.

Chuyện gì vừa xảy ra với PHP?

PHP là một ngôn ngữ lập trình làm web. Ai chê PHP thì chê, chứ số website chạy PHP vẫn đông top đầu thế giới: web bán hàng, trang giới thiệu công ty, landing page chạy quảng cáo.. Đa số website doanh nghiệp đang chạy WordPress, mà WordPress cũng là PHP luôn.

Ngày 21/10/2026, PHP công bố và vá 2 lỗ hổng: CVE-2026-109618 và CVE-2026-109619, gọi chung là PHP2Shell. Mức nghiêm trọng 9.2/10.

Giải thích nôm na cho dễ hình dung vầy:

Nguyên cái toà chung cư của anh chị xài chung một loại ổ khoá. Rồi có người phát hiện loại khoá này không cần chìa, lấy cái kẹp giấy chọt chọt vô là mở được. Đứng ngoài cửa là vào. Vào rồi muốn làm gì trong nhà cũng được.

Trong ngôn ngữ kỹ thuật thì kẻ xấu có thể chạy lệnh trên máy chủ website từ xa mà không cần đăng nhập. Hậu quả: lộ dữ liệu khách hàng, web bị cài mã độc, hoặc bị biến thành chỗ phát tán lừa đảo.

Vài chi tiết làm mình rùng mình:

• Lỗi ảnh hưởng PHP từ bản 5.4 (ra năm 2012) trở đi. Nghĩa là cái ổ khoá hỏng đã nằm trên cửa khoảng 14 năm.
• Các kiểu chạy PHP phổ biến đều dính, trong đó Apache mod_php rủi ro cao nhất.
• Amazon ghi nhận đã có người thử khai thác từ 17/10, tức trước ngày công bố 4 ngày. Chủ nhà chưa biết gì thì đã có người đi thử từng cánh cửa rồi.

AI tìm ra lỗi, rồi OpenAI tung luôn “skill” kiểm tra

Lỗi này được hai công ty bảo mật Calif và Wiz tìm ra nhờ AI, nằm trong chương trình “Patch the Planet” do OpenAI dẫn dắt. Nghe tên “vá cả hành tinh” đúng kiểu phim Marvel của Tây lông :3

Rồi ông cố OpenAI vừa post trên X, tung luôn một “skill” cho Codex (trợ lý lập trình của OpenAI) để AI tự kiểm tra xem web của bạn dính chưa. Đúng kiểu tát nước theo mưa. Đọc chưa kịp cười thì thấy anh Hồng Phúc bêu tên bên tường nhà ảnh: “đúng kiểu tạo vấn đề bán giải pháp” :))

Câu đùa cay thiệt. Nhưng phải tách làm hai tầng mới thấy rủi ro thật nằm ở đâu.

Tầng 1: bản thân cái skill gần như vô hại

Mình mở ra xem thử, cũng chả có vẹo gì. Skill của OpenAI chỉ đọc số phiên bản PHP mà website tự khai ra, rồi so với mốc đã vá. Kiểu nhìn biển số xem xe có thuộc đợt “triệu hồi” này không thôi.

Nó không chứa mã tấn công, cũng không biết web của bạn đã bị ai mò vô chưa.

Kẻ xấu dùng nó để lập danh sách web chưa vá được không? Được. Nhưng mấy cha đó vốn đã làm việc này hằng ngày bằng công cụ quét có sẵn hơn 20 năm nay. Trộm vốn có ống nhòm rồi, thêm cái skill này cũng chẳng hơn là bao.

Tầng 2: cái đáng sợ thật là bộ não AI phía sau

Bỏ qua mục đích “tốt đẹp” mà mấy cha tư bản bàn, thì AI giờ đúng là vừa tìm ra lỗi (xong la làng liền), mà cũng vừa “độ” được mã khai thác lỗ hổng còn ác hơn.

Theo các bài tường thuật, nhóm nghiên cứu đã dùng AI để chỉnh cách khai thác cho từng phiên bản, từng cấu hình PHP khác nhau. Tức là AI không chỉ chỉ ra ổ khoá hỏng, mà còn chỉ luôn cách mở ở từng kiểu cửa. Năng lực đó nằm trong model, không nằm trong cái skill. Người tốt có thì kẻ xấu cũng sẽ có.

Trước đây doanh nghiệp còn vài tuần từ lúc lỗi được công bố tới lúc bị tấn công hàng loạt. Giờ AI đọc bản vá, suy ra cách khai thác rồi quét cả Internet nhanh hơn rất nhiều. Thời gian để thay khoá co lại còn vài giờ.

Nên tốc độ khắc phục, mình nghĩ chắc khó mà theo kịp tốc độ “phá hoại”. Cách duy nhất là cũng phải dùng AI để đội IT tăng tốc vá, giảm thiểu rủi ro thôi.

Nói đi cũng phải nói lại

Tự cãi lại miếng, kẻo nói một chiều.

Nói OpenAI “tạo vấn đề” thì chưa công bằng lắm. AI không tạo ra cái lỗi. Cái khoá hỏng đã nằm đó 14 năm, AI chỉ là ông thợ khoá nhìn ra trước. Phe tốt không dùng AI thì phe xấu vẫn dùng, ngồi yên không làm thế giới an toàn hơn, chỉ để kẻ xấu đi trước một nhịp.

Lần này công bố cũng có phối hợp đàng hoàng: bản vá ra cùng ngày, Cloudflare bật lớp chặn cho khách khoảng 9 tiếng trước đó.

Còn chuyện cùng một công ty vừa bán năng lực AI cho cả thế giới, vừa đứng ra dẫn dắt chương trình vá lỗi cho cả thế giới.. thì đúng là mô hình hai đầu đều có lời. Không phải âm mưu gì, nhưng châm biếm nó thì cũng chính đáng (hổng biết mình nghĩ vậy đúng hem).

Bài học cho doanh nghiệp: câu hỏi không còn là “AI có bị lạm dụng không”, chắc chắn là có rồi. Câu hỏi là công ty mình thay khoá nhanh tới đâu.

CEO và quản lý cần hỏi IT 5 câu

Anh chị doanh chủ, CEO hay quản lý không cần hiểu kỹ thuật. Chỉ cần có câu trả lời cho 5 câu này trong hôm nay:

1. Công ty có những website, hệ thống nào chạy PHP? Web bán hàng, WordPress, landing page, web cũ của chiến dịch đã xong, web agency làm hộ, hệ thống nội bộ. Kể hết, kể cả mấy cái lâu rồi không ai đụng tới.
2. Từng cái đã lên bản vá chưa, ai xác nhận, lúc mấy giờ? Đòi xác nhận bằng văn bản, có ghi rõ phiên bản PHP.
3. Cái nào chưa vá được thì đang che chắn tạm bằng gì? Tường lửa web, chặn upload, hay tắt tạm.
4. Đã kiểm tra dấu hiệu bị xâm nhập từ ngày 17/10 chưa? Vì có người thử cửa từ trước ngày công bố 4 ngày.
5. Lần sau có lỗi kiểu này, mình vá trong bao lâu và ai chịu trách nhiệm?

Không trả lời được câu 1 là rủi ro lớn nhất. Không biết nhà mình có mấy cánh cửa thì thay khoá kiểu gì.

Mấy cái web cũ của chiến dịch đã xong là cửa sau nguy hiểm nhất. Không ai nhớ, không ai vá, mà vẫn nằm đó mở ra Internet.

Thêm một lưu ý: cập nhật WordPress, plugin hay theme KHÔNG vá được lỗi này. Lỗi nằm ở chính PHP, tức là nằm ở cái ổ khoá chứ không phải ở cánh cửa. Web thuê hosting thì gọi nhà cung cấp, đòi họ xác nhận đã nâng PHP.

Nói thiệt, công ty mình nhỏ mà lâu quá giờ mình cũng mò chưa ra hết đâu mà lần :3 Mấy cái landing page chạy chiến dịch từ mấy năm trước, mình cũng đang phải đi lục lại từng cái.

Chuyện “không biết mình có gì” này thật ra cũng là một kiểu thất bại khi áp dụng công nghệ, mình có kể kỹ hơn ở bài 1001 cách để doanh nghiệp áp dụng công nghệ thất bại.

Checklist cho đội IT

Phần này dài, mà chắc cú anh em IT cũng tự biết làm rồi. Mình gom lại theo nguồn chính thức của PHP, Amazon, Cloudflare, Google Cloud (cập nhật 22/10/2026) để anh chị CEO có cái chuyển thẳng cho đội, khỏi phải gõ lại.

Bước 0: xác định có bị ảnh hưởng không (1 - 2 giờ đầu)

(Viết cho anh em IT nên bắt đầu từ số 0 nhe ^^)

• Kiểm kê mọi máy chủ, container, hosting có PHP: web công khai, trang quản trị, API, hệ thống nội bộ, staging/dev đang mở ra Internet. Một máy chủ có thể cài nhiều phiên bản PHP (cPanel MultiPHP, Plesk..), kiểm từng bản.
• Ghi lại phiên bản PHP đang phục vụ web, không chỉ php -v. Bản dòng lệnh (CLI) và bản chạy web (PHP-FPM, Apache mod_php) có thể khác nhau. Chắc nhất là kiểm gói hoặc binary của PHP-FPM, hoặc bật phpinfo() tạm trên trang chỉ nội bộ truy cập được rồi xoá ngay.
• Phạm vi: mọi PHP từ 5.4 tới trước bản vá, với các kiểu chạy PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. Apache mod_php rủi ro cao nhất: đã có bản khai thác chạy được với cấu hình mặc định, trước cả khi code ứng dụng kịp chạy.
• Ưu tiên theo mức phơi nhiễm: web công khai có form hoặc upload trước, rồi tới trang quản trị và API công khai, sau cùng là hệ thống chỉ chạy trong mạng nội bộ.

Về công cụ openai/php2shell-checker: nó chỉ so số phiên bản (đọc header của website, hoặc php -v trên máy chủ). Header bị ẩn thì ra UNKNOWN, không có nghĩa là an toàn. Ra OK cũng chỉ là khớp số, không chứng minh bản vá đã cài. Bản phân phối Linux vá kiểu backport còn có thể bị báo sai. Tham khảo thôi nha.

Bước 1: vá (hệ thống công khai thì xong trong ngày)

Nâng PHP lên bản đã vá:

Nhánh	Bị ảnh hưởng	Bản đã vá
8.5	8.5.0 - 8.5.11	8.5.12
8.4	8.4.0 - 8.4.26	8.4.27
8.3	8.3.0 - 8.3.35	8.3.36
8.2	8.2.0 - 8.2.34	8.2.35
8.1 trở xuống	tất cả	không có bản phát hành vá

• Dùng gói của bản phân phối Linux (Ubuntu, Debian, RHEL/AlmaLinux/Rocky..) thì cập nhật theo thông báo bảo mật của chính bản phân phối (USN, DSA, RHSA). Gói vá kiểu backport thường giữ nguyên số phiên bản gốc, ví dụ Ubuntu 22.04 vẫn là PHP 8.1.2 nhưng gói 8.1.2-1ubuntu2.28 đã có bản vá. Đối chiếu số hiệu gói, đừng chỉ nhìn số phiên bản PHP.
• Máy chủ Windows/IIS: tải bản vá từ php.net, cập nhật thủ công.
• PHP 8.1 trở xuống: nâng lên 8.2+ đã vá. Chưa nâng được ngay thì dùng bản backport của nhà phân phối hoặc nhà cung cấp hỗ trợ dài hạn nếu có. Đội tự build PHP có thể dùng nhánh vá tối thiểu PHP công bố cho 7.4, 8.0, 8.1 (không phải bản phát hành chính thức). Trong lúc chờ thì làm Bước 2. PHP 8.2 cũng hết hỗ trợ ngày 31/12/2026, tính luôn đường lên 8.3+.
• Khởi động lại PHP sau khi cập nhật (PHP-FPM, Apache, LiteSpeed..). Chưa restart thì tiến trình cũ vẫn chạy code lỗi. Thay khoá mới mà cửa vẫn để cái khoá cũ trên đó.
• Container/Docker: build lại image từ base image đã vá rồi deploy lại.
• Hosting chia sẻ, cPanel, agency quản lý: yêu cầu cập nhật PHP và xác nhận bằng văn bản phiên bản đã lên.
• Vá xong kiểm lại: phiên bản (hoặc số hiệu gói) đang phục vụ web đúng như mong đợi.

Bước 2: che chắn tạm nếu chưa vá kịp

Nói vậy là tại đâu phải cái gì muốn làm là làm liền được. Web đang vận hành thật thì đụng đâu ảnh hưởng đó. Nhưng PHP nói rõ: mấy biện pháp dưới đây chỉ chặn MỘT SỐ đường tấn công, cập nhật mới là cách sửa duy nhất. Thuê bảo vệ đứng trước cửa thì tốt, chứ không thay được cái khoá.

Tường lửa web (WAF):

• Cloudflare: gói Free được bảo vệ mặc định từ 21/10 (03:02 UTC), không cần làm gì. Gói trả phí thì kiểm tra Managed Ruleset đang ở chế độ Block. WAF chỉ có tác dụng khi tên miền bật proxy (đám mây cam) và máy chủ gốc không truy cập trực tiếp được từ Internet.
• Google Cloud Armor: tối thiểu bật nhóm luật File Upload và RFI.
• AWS và WAF khác: bật luật quản lý theo hướng dẫn của nhà cung cấp.
• Kẻ tấn công đang biến tấu mã để lách WAF, nên WAF chỉ là lớp phụ.

Chặn đường tấn công qua bộ nhớ (CVE-2026-109618):

• Đặt memory_limit = -1 bằng php_admin_value trong pool PHP-FPM hoặc cấu hình Apache, để ứng dụng không ghi đè được. Rà xem còn chỗ nào (pool, thư mục, ứng dụng) đặt lại giới hạn hữu hạn không.
• Giới hạn bộ nhớ ở cấp container hoặc cgroup để một tiến trình không ăn hết RAM.
• KHÔNG dùng ulimit -v hay LimitAS= / LimitDATA= của systemd (RLIMIT_AS / RLIMIT_DATA), vì chính chúng kích hoạt lỗi.

Hạn chế upload và kích thước request:

• post_max_size thấp: 8M nếu không cần upload, 32M nếu cần. upload_max_filesize nhỏ hơn post_max_size.
• Ở web server hoặc proxy, giới hạn kích thước request đã giải mã, số trường, số phần multipart, số header và độ sâu lồng nhau. Giới hạn phải áp cả với request không có Content-Length (chunked).
• Ứng dụng không cần upload thì cân nhắc chặn multipart upload, nhớ đánh giá ảnh hưởng trước.

Chặn đường tấn công qua session (CVE-2026-109619):

• Đặt session.upload_progress.enabled = 0 trong php.ini hoặc pool PHP-FPM, rồi khởi động lại toàn bộ worker. Không đặt bằng ini_set() hay .user.ini. Không dùng tính năng này thì tắt luôn kể cả sau khi vá.
• PHP 8.5: đặt thêm fatal_error_backtraces = 0 rồi restart worker.
• Gỡ các thiết lập PHP sai hoặc lỗi thời đặt theo từng request (trong .htaccess, fastcgi_param PHP_VALUE của nginx..). Chỉ ẩn lỗi bằng display_errors, error_reporting hay @ thì không có tác dụng.

Còn lại:

• Trang quản trị: giới hạn theo IP hoặc VPN cho chắc.
• Web cũ không còn dùng: tắt hẳn. Cửa không ai đi thì xây bít luôn.

Bước 3: rà dấu hiệu xâm nhập từ 17/10/2026

Cái này đừng quên. Thay khoá xong rồi thì phải coi lại camera, xem mấy hôm trước có ai đã vô nhà chưa.

• Rà log web từ 17/10/2026: request POST upload (multipart) chứa chuỗi PHP_SESSION_UPLOAD_PROGRESS, lỗi 500 hoặc tiến trình PHP chết bất thường.
• Đối chiếu các IP Amazon ghi nhận đã thử khai thác: 103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37. Đây là hạ tầng ẩn danh dùng chung, dùng để điều tra chứ đừng chặn cứng.
• Tìm file lạ hoặc mới sửa trong thư mục web (nhất là file .php trong thư mục upload), webshell, plugin lạ.
• Kiểm tra tài khoản quản trị mới, cron job lạ, tiến trình lạ do user chạy web sinh ra, kết nối ra ngoài bất thường.
• Nghi bị xâm nhập thì: cô lập máy chủ, giữ nguyên log để điều tra; đổi mật khẩu, khoá API, thông tin kết nối database nằm trên máy đó; ưu tiên dựng lại máy sạch thay vì “dọn dẹp”; có dữ liệu khách hàng thì liên hệ đơn vị ứng cứu sự cố.

Bước 4: sau sự cố (trong tuần)

• Lập danh sách tài sản số: website, máy chủ, phiên bản, người phụ trách. Cập nhật định kỳ.
• Cam kết thời gian vá: lỗ hổng nghiêm trọng trên hệ thống công khai thì vá trong vài giờ tới 24 giờ, có người trực.
• Bật cập nhật bảo mật tự động, base image tự cập nhật ở chỗ nào làm được.
• Giữ WAF bật thường trực cho mọi web công khai.
• Theo dõi kênh cảnh báo bảo mật của PHP, bản phân phối Linux, nhà cung cấp hosting và cloud.
• Lên kế hoạch thoát khỏi PHP hết hỗ trợ: 8.1 trở xuống, và 8.2 (hết hạn 31/12/2026).

Lưu ý: số hiệu gói vá của Debian, Red Hat, cPanel mình chưa đối chiếu được với thông báo gốc, nên chỉ khuyên kiểm tra thông báo bảo mật của từng bản phân phối. Tình hình còn đang cập nhật, trước khi xử lý đội IT nên xem lại thông báo mới nhất của PHP và nhà cung cấp.

Tóm lại

Cái khoá hỏng 14 năm không phải lỗi của AI. Nhưng từ giờ trở đi, người tìm ra khoá hỏng và người mở được khoá hỏng đều có AI trong tay. Khoảng cách giữa hai bên tính bằng giờ.

Không còn là tuần. Là giờ.

Nên việc của doanh nghiệp không phải là lo AI tốt hay xấu, mà là biết nhà mình có mấy cánh cửa, ai giữ chìa, và thay khoá nhanh cỡ nào.

Mà nói vậy thôi, viết thì dễ chứ ngồi kiểm kê thì mỏi tay lắm. Mai rảnh mình đi lục tiếp mấy cái web cũ đây..

Công ty anh chị đã trả lời được câu số 1 chưa: nhà mình có bao nhiêu website chạy PHP? Comment cho mình biết với, hay anh em IT nào có mẹo kiểm kê nhanh thì chia sẻ luôn cho mọi người nhé.

Chúc anh em “ngủ ngon” ^^

#voquoccuong #php2shell #baomat #lanhdaoai

Nguồn tham khảo:

• PHP Security Release 21/10/2026: php.net/archive/2026.php
• PHP advisory CVE-2026-109618: GHSA-w8hw-w9fx-j79w
• PHP advisory CVE-2026-109619: GHSA-6wmf-4rv5-p3rp
• Cloudflare, bảo vệ WAF cho PHP2Shell: blog.cloudflare.com
• Amazon Threat Intelligence, khai thác trước ngày công bố (mốc 17/10, danh sách IP): aws.amazon.com
• Google Cloud, phạm vi từ PHP 5.4 và Cloud Armor: cloud.google.com
• OpenAI php2shell-checker: github.com/openai/php2shell-checker
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching: cisa.gov
• Wiz, PHP2Shell và vai trò của AI: wiz.io
• Qualys: blog.qualys.com
• BleepingComputer: bleepingcomputer.com
• Help Net Security: helpnetsecurity.com
• CNN: edition.cnn.com
• Fortune: fortune.com
• GIGAZINE: gigazine.net
• Gizmodo, OpenAI Wants to “Patch the Planet”: gizmodo.com