BTC

$96,000

5.73%

ETH

$3,521.91

3.97%

HTX

$0.{5}2273

5.23%

SOL

$198.17

3.05%

BNB

$710

3.05%

简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

PHP phát hiện lỗ hổng nghiêm trọng cấp độ "Internet", điểm yếu "ngoài chuỗi" của Web3 nên được khắc phục thế nào?

Đọc bài viết này mất 28 phút

PHP khẩn cấp vá hai lỗ hổng thực thi mã từ xa điểm CVSS 9.2, ảnh hưởng đến các phiên bản từ 5.4 đến 8.5.11, chi tiết bị rò rỉ trước và đã bị khai thác. Khoảng 53% tên miền trong ngành crypto sử dụng PHP, các nền tảng Web3 cần nâng cấp càng sớm càng tốt.

Tiêu đề gốc: "PHP phát hiện lỗ hổng nghiêm trọng cấp 'Internet', 'điểm yếu off-chain' của Web3 cần được vá như thế nào?"
Tác giả gốc: Nhóm bảo mật SlowMist

Chuyện gì đã xảy ra

Ngày 21 tháng 10, dự án PHP đã phát hành bản cập nhật bảo mật khẩn cấp, vá hai lỗ hổng nghiêm trọng CVE-2026-109618 và CVE-2026-109619 có thể dẫn đến thực thi mã từ xa (RCE) chưa xác thực; cả hai đều được đánh giá 9.2 điểm theo CVSS v4.0. PHP chính thức tuyên bố rõ ràng rằng trước khi vá, tất cả các cài đặt PHP cung cấp dịch vụ web ra bên ngoài đều có thể bị ảnh hưởng.

Ngày 20 tháng 10, chi tiết lỗ hổng đã bị rò rỉ trước khi được công bố chính thức, bản vá vẫn chưa được phát hành. Nhóm bảo mật PHP buộc phải đẩy bản phát hành khẩn cấp từ ngày 22 tháng 10 theo kế hoạch lên ngày 21 tháng 10 lúc 14:00 (UTC).

Đáng cảnh giác hơn là, cuộc tấn công có thể diễn ra sớm hơn cả công bố. Nhóm tình báo mối đe dọa của Amazon báo cáo rằng họ đã quan sát thấy các nỗ lực khai thác nhắm vào php2shell trong mạng honeypot MadPot của mình từ ngày 17 tháng 10, sớm hơn bốn ngày so với công bố công khai.

SlowMist cũng đã đưa ra cảnh báo và khuyến nghị bảo mật ngay sau khi PHP chính thức đưa ra thông báo trước.

Hai lỗ hổng lần lượt là gì

CVE-2026-109618 (hỏng bộ nhớ OOM): Khi bộ nhớ PHP cạn kiệt, quy trình xử lý sẽ bị gián đoạn, lúc này dữ liệu trong tay chỉ mới chuẩn bị được một nửa. Khi dọn dẹp kết thúc, PHP lại coi những sản phẩm dở dang này là dữ liệu hoàn chỉnh để sử dụng, kết quả là bộ nhớ bị rối loạn.

CVE-2026-109619 (trạng thái toàn cục cũ): Sau khi một yêu cầu được xử lý xong, bộ nhớ đã được giải phóng, nhưng trạng thái liên quan vẫn "nằm nguyên tại chỗ". Khi cùng một tiến trình công việc tiếp nhận yêu cầu tiếp theo, nó có thể sử dụng trạng thái quá hạn này trước khi khởi tạo bình thường. Chính thức đã xác nhận, có thể lợi dụng điều này để tấn công PHP-FPM và thực hiện thực thi mã từ xa.

Xét về đường tấn công, điểm nguy hiểm của loại lỗ hổng này là kẻ tấn công không cần phải có tài khoản trang web trước, cũng không cần vượt qua xác thực đăng nhập, quyền hạn hay API Key ở tầng nghiệp vụ. Chỉ cần gửi một yêu cầu được构造 đến ứng dụng PHP lộ ra Internet công cộng, là có thể thực thi mã tùy ý với quyền của tiến trình dịch vụ web.

Phạm vi ảnh hưởng: PHP 5.4 đến 8.5.11 đều bị ảnh hưởng. Phiên bản sửa lỗi là 8.5.12, 8.4.27, 8.3.36 và 8.2.35. PHP 8.1 và các phiên bản cũ hơn đã ngừng hỗ trợ thông thường từ上游, không thể trông chờ kênh thông thường phát hành bản vá, nên di chuyển sang phiên bản vẫn được hỗ trợ.

Tại sao cả thế giới đều căng thẳng?

Vì PHP thực sự quá phổ biến. Theo thống kê của W3Techs, trong số các trang web có thể nhận diện ngôn ngữ máy chủ, 69,3% sử dụng PHP. WordPress, WooCommerce, Magento – những hệ thống quen thuộc – đều chạy trên nền nó.

Phản ứng của các nước cũng cho thấy vấn đề – Trung tâm An ninh mạng Quốc gia Hà Lan từng đóng cửa trang web mang tính phòng ngừa; Văn phòng Tổng thống Hàn Quốc đã triệu tập cuộc họp an ninh mạng khẩn cấp, chính phủ nâng mức cảnh báo an ninh mạng.

Ngoài ra, theo báo cáo, gần như tất cả các trang web chính thức của Triều Tiên, bao gồm truyền thông chính thức và cổng thông tin chính phủ, đã ngoại tuyến hơn 24 giờ, hiện chưa rõ có liên quan đến sự cố lỗ hổng này hay không.

Tác động đến Web3

Đây không phải là vấn đề chỉ liên quan đến vận hành trang web truyền thống. Đối với Web3, hợp đồng on-chain dù không có lỗ hổng, nhưng rất nhiều "khâu off-chain" vận hành xung quanh hợp đồng, bao gồm trang frontend, API, ví lưu ký, dịch vụ ký, trang nhận airdrop, backend vận hành và dịch vụ dữ liệu, nhiều cái được xây dựng bằng PHP (WordPress, WooCommerce, Magento, v.v.). Bản thân hợp đồng không có lỗ hổng cũng không có nghĩa là các khâu này an toàn.

Theo thống kê của hệ thống tình báo mối đe dọa MistEye thuộc SlowMist, trong 1488 tên miền liên quan đến ngành crypto được quét, 793 tên miền có dấu vết PHP trực tiếp, khoảng 53,3%. Cần nhấn mạnh, điều này chỉ cho thấy đã dùng PHP, không có nghĩa là các trang web này có lỗ hổng hoặc đã bị xâm phạm.

1. Phía nền tảng: một số con đường rủi ro điển hình

Giao diện người dùng bị giả mạo, người dùng bị dụ dỗ ký.

Nếu máy chủ của các trang web DeFi, ví hoặc trang airdrop bị kiểm soát, kẻ tấn công có thể thay thế địa chỉ RPC, đối tượng ủy quyền, địa chỉ hợp đồng hoặc thông báo ký trong trang, biến một giao dịch bình thường thành ủy quyền độc hại, tương tác hợp đồng độc hại hoặc quy trình nạp tiền giả. Kẻ tấn công không cần phá vỡ hợp đồng, chỉ cần khiến người dùng tự ký một ủy quyền độc hại.

Rò rỉ khóa và thông tin xác thực.

Sau khi máy chủ bị kiểm soát, kẻ tấn công có thể đọc tệp cấu hình, mật khẩu cơ sở dữ liệu, API Token, biến môi trường, v.v. Nếu phần backend dùng PHP để kết nối với node RPC hoặc dịch vụ ví nóng, một khi API Key, token phiên bị rò rỉ, có thể leo thang thành việc tài sản trong ví nóng bị chuyển đi hoặc quyền ký bị lạm dụng.

Backend và API bị chiếm quyền.

Các sàn giao dịch, chợ NFT, cầu nối cross-chain, cổng thanh toán và nhà cung cấp dịch vụ node thường có backend vận hành, cùng với giao diện KYC/kiểm soát rủi ro, phân bổ địa chỉ nạp tiền, phê duyệt rút tiền, hệ thống ticket, v.v. Sau khi có được quyền, kẻ tấn công có thể sửa cấu hình, đánh cắp dữ liệu người dùng, tạo tài khoản có quyền cao hoặc vượt qua quy trình nghiệp vụ.

Di chuyển ngang qua chuỗi cung ứng.

Quyền của tiến trình PHP thường không bằng quyền cao nhất của máy chủ, nhưng nếu nó có thể đọc được khóa CI/CD, socket runtime của container, thông tin xác thực cơ sở dữ liệu hoặc token truy cập đám mây, phạm vi tấn công có thể mở rộng từ một node Web sang cơ sở dữ liệu, hệ thống build, thậm chí toàn bộ tài khoản production.

Plugin thanh toán và dịch vụ bên thứ ba.

Được biết, các giải pháp thanh toán tiền mã hóa như Binance Pay, Crypto.com Pay, BitPay, CoinGate, CoinPayments đều có tích hợp WooCommerce, máy chủ không được vá sẽ có rủi ro phơi nhiễm nghiêm trọng. Các dịch vụ bên thứ ba như RPC, trình duyệt khối, nền tảng phân tích dữ liệu, nếu backend hoặc hệ thống vận hành chạy trên môi trường PHP bị ảnh hưởng, cũng có thể trở thành điểm xâm nhập. Tất nhiên, bản thân node RPC, hợp đồng thông minh, trình duyệt khối và ví không phụ thuộc tự nhiên vào PHP, điều này phụ thuộc vào tech stack của sản phẩm cụ thể.

Nhưng cần lưu ý, máy chủ bị xâm nhập không đồng nghĩa với việc tài sản trên chuỗi chắc chắn bị đánh cắp. Từ khi dịch vụ Web bị xâm nhập đến khi thực sự mất tiền, còn phải xem kẻ tấn công có thể tiếp cận thông tin xác thực nhạy cảm, quy trình ký, quyền quản trị hay các khâu tương tác người dùng hay không. Ví nóng có được cách ly với lớp Web hay không, khóa có được đặt trong HSM/KMS hay không, quyền hạn có được tối thiểu hóa hay không, trực tiếp quyết định mức tổn thất tối đa.

2. Người dùng thông thường: Có nên rút coin ra không?

Không cần.

Lý do rất đơn giản:

Lỗ hổng lần này ảnh hưởng đến môi trường máy chủ đáp ứng các điều kiện cụ thể, không có nghĩa là ví của tất cả người dùng đều gặp rủi ro.

Duyệt trang web, kết nối ví không giống với việc rò rỉ khóa riêng tư. Bản thân lỗ hổng không thể trực tiếp phá vỡ ví hoặc chữ ký của người dùng.

Một dự án có thể dùng PHP, không có nghĩa là nó đã gặp sự cố. Không có lý do để giả định mọi sàn giao dịch đều đã bị xâm nhập, càng không cần vì thế mà rút toàn bộ tài sản. Điều người dùng thực sự cần cảnh giác là liệu trang web mình truy cập có đã bị xâm nhập hay chưa. Người dùng không thể phán đoán một trang web đã được vá lỗi hay chưa, nên sự kiện lần này là một lời nhắc nhở: đừng mù quáng tin tưởng giao diện trang web. Kẻ tấn công còn có thể lợi dụng sức nóng dư luận để phát tán trang đăng nhập giả, cổng bồi thường giả, yêu cầu kết nối ví độc hại.

Nếu dự án chính thức xác nhận trang web hoặc hệ thống quản trị bị xâm nhập, hãy căn cứ vào ảnh hưởng thực tế được công bố để quyết định có tạm dừng tương tác, kiểm tra giao dịch bất thường, thu hồi ủy quyền đáng ngờ hay không. Nếu xác nhận khóa riêng tư ký hoặc cụm từ khôi phục đã bị rò rỉ, phải xử lý như sự cố rò rỉ khóa, chỉ đổi mật khẩu hoặc ngắt kết nối trang web là không đủ. Người dùng bot giao dịch, công cụ thực thi tự động hoặc dịch vụ triển khai đám mây cũng cần chú ý xem dịch vụ liên quan có phát hành phiên bản bị ảnh hưởng hoặc thông báo luân chuyển thông tin xác thực hay không.

Cách ứng phó

1. Nền tảng và bên dự án:

Bước đầu tiên: Nắm rõ tình hình, nâng cấp càng sớm càng tốt

Kiểm kê toàn bộ tài sản PHP trên mạng công cộng và mạng nội bộ: máy chủ, image container, workload Kubernetes, CMS cũ, hệ thống quản trị, môi trường do đối tác vận hành, plugin bên thứ ba và dịch vụ lưu trữ. Dấu vân tay kỹ thuật chỉ có thể dùng làm manh mối, không thể trực tiếp coi là kết luận "xác nhận có lỗ hổng".

Nâng cấp lên 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, hoặc áp dụng bản vá tương đương do nhà phân phối, nhà cung cấp đám mây, nhà cung cấp dịch vụ lưu trữ cung cấp. Nếu đang dùng 8.1 và các phiên bản cũ hơn, hãy yêu cầu nhà cung cấp backport hoặc di chuyển càng sớm càng tốt. «Môi trường cũ ổn định» «ứng dụng ít cập nhật» đều không thể làm giảm rủi ro của lỗ hổng này.

Sau khi nâng cấp, hãy xây dựng lại container image, khởi động lại cuốn chiếu hoặc thay thế toàn bộ tiến trình PHP worker, và kiểm tra phiên bản runtime thực tế đang xử lý yêu cầu trên môi trường trực tuyến, chứ không chỉ phiên bản trên máy build hoặc trong dòng lệnh.

Bước hai: Nếu tạm thời chưa thể nâng cấp thì phải làm gì

Trước tiên hãy thu hẹp bề mặt phơi nhiễm để tranh thủ thời gian, nhưng điều này không thể thay thế bản vá:

Cô lập các ứng dụng PHP phơi nhiễm ra Internet công cộng, hoặc thêm xác thực mạng và kiểm soát truy cập ở lớp cổng vào.

Tắt các chức năng tải tệp lên không cần thiết, từ chối các yêu cầu multipart/form-data không cần thiết ở lớp WAF hoặc máy chủ Web.

Một số khuyến nghị bảo mật còn bao gồm: đặt memory_limit=-1, tắt session.upload_progress.enabled, và trên PHP 8.5 tắt thêm fatal_error_backtraces. Các cấu hình này có tác dụng phụ về nghiệp vụ và tính khả dụng, cần kiểm thử trước, sau mỗi lần thay đổi phải khởi động lại toàn bộ PHP worker.

Bước ba: Kiểm tra xem có bị xâm nhập hay không, và dọn dẹp thông tin xác thực

Đối với các dịch vụ bị ảnh hưởng từng phơi nhiễm ra Internet công cộng, hãy kết hợp nhật ký, giám sát đầu cuối và các kết nối mạng bất thường để điều tra, ví dụ tiến trình PHP đột nhiên khởi chạy lệnh hệ thống. Nếu phát hiện dấu hiệu xâm nhập, trước tiên hãy bảo toàn bằng chứng, sau đó xử lý theo quy trình ứng phó sự cố.

Giả định tình huống xấu nhất: đối với các máy chủ chưa được vá kịp thời, hãy luân chuyển API key, khóa phiên, chứng chỉ TLS, mật khẩu cơ sở dữ liệu, token truy cập đám mây, thông tin xác thực CI/CD, RPC/API Key, khóa Webhook và Token bên thứ ba, đồng thời kiểm tra xem có ghi nhận sử dụng bất thường hay không.

Nếu trong môi trường từng cài đặt hoặc chạy phiên bản phần mềm đã được xác nhận bị nhiễm độc, chỉ nâng cấp hoặc cài đặt lại không thể chứng minh rủi ro đã được loại bỏ, mà còn phải điều tra rò rỉ thông tin xác thực và backdoor duy trì, nếu cần hãy xây dựng lại một môi trường sạch.

Bước 4: Giữ vững bề mặt kiểm soát tài sản

Vá PHP không nên là hành động duy nhất. Càng phải đảm bảo rằng "một máy Web bị xâm nhập sẽ không kéo theo hệ thống tài chính":

Cô lập hoàn toàn khóa riêng tư của ví nóng, ví thu gom và dịch vụ ký quan trọng khỏi các nút Web. Sử dụng HSM, MPC, mạng ký chuyên dụng hoặc chính sách KMS với quyền tối thiểu.

Đặt dịch vụ Web, dịch vụ ký, nút on-chain, cơ sở dữ liệu và hệ thống build vào các phân đoạn mạng và ranh giới danh tính khác nhau.

Trong thời gian sự cố, tạm thời thắt chặt các thao tác rủi ro cao như rút tiền, thay đổi danh sách trắng địa chỉ, nâng quyền quản trị viên, tạo API Key, sửa đổi quy tắc kiểm soát rủi ro, và nếu cần thì bật xác minh thủ công hoặc trì hoãn có hiệu lực.

Các dịch vụ tự động thực thi on-chain có thể áp dụng ký độc lập, phê duyệt đa chữ ký, giới hạn hạn mức giao dịch và cơ chế vô hiệu hóa khẩn cấp tùy theo nghiệp vụ.

Kiểm tra tài nguyên tĩnh của trang web, gói JavaScript, cấu hình reverse proxy, quy tắc DNS/CDN và dịch vụ xây dựng giao dịch, xác nhận không bị chèn script độc hại hoặc bị thay thế.

2. Người dùng thông thường:

Đi qua cổng chính thức: Gần đây hãy cố gắng truy cập nền tảng qua bookmark hoặc kênh chính thức, cảnh giác với bất kỳ liên kết nào được gửi đến dưới danh nghĩa "sự cố bảo mật".

Đừng chỉ nhìn tên miền và giao diện: Ngay cả với tên miền dApp quen thuộc, script trang, tham số giao dịch, cấu hình RPC cũng có thể bị kẻ xâm nhập phía máy chủ thay thế.

Kiểm tra từng mục trước khi ký: Địa chỉ nhận, chuỗi, hạn mức ủy quyền, hợp đồng được gọi và kết quả mô phỏng giao dịch. Đặc biệt cẩn thận với approve và setApprovalForAll, càng phải thận trọng với ủy quyền hạn mức vô hạn.

Cảnh giác với "bồi thường", "di chuyển", "xác minh lại": Trong thời gian sự cố có thể xuất hiện các thông báo như "đăng nhập lại", "xác minh lại ví", "di chuyển tài sản", "nhận bồi thường". Không chỉ dựa vào cửa sổ bật lên trong trang, mà phải xác minh chéo từ nhiều kênh chính thức của dự án.

Phân tầng tài sản: Dùng ví phần cứng để lưu trữ tài sản lớn, tương tác hàng ngày dùng ví riêng biệt có hạn mức, và định kỳ dọn dẹp các ủy quyền. Như vậy ngay cả khi một giao diện hoặc nền tảng gặp sự cố, tổn thất mỗi lần cũng có giới hạn.

Có bất thường thì dừng lại trước: Khi gặp yêu cầu ký bất thường, nhắc nhở ủy quyền không lường trước, hoặc hành vi trang web có gì đó không ổn, hãy tạm dừng trước, rồi xác minh qua kênh chính thức.

Cuối cùng muốn nói

Các lỗ hổng thực thi mã từ xa không cần đăng nhập như PHP2Shell, một khi vượt qua lớp Web, các cuộc xâm nhập máy chủ truyền thống có thể tiến hóa thành đầu độc giao diện, mạo danh danh tính, lạm dụng quyền ký, rủi ro ví nóng, thậm chí xâm nhập ngang ở cấp chuỗi cung ứng.

Đối với nền tảng, ba việc ưu tiên nhất là: nâng cấp lên phiên bản đã vá, cô lập các môi trường cũ tạm thời không thể vá, kiểm toán khóa và mặt phẳng kiểm soát tài sản. Sau khi nâng cấp, còn phải coi việc rà soát dấu hiệu xâm nhập là một phần của ứng phó sự cố. Đối với người dùng, trong thời gian này cần bớt tin tưởng mù quáng vào giao diện trang, trước mỗi lần ký hãy nhìn thêm một chút. Nhưng cũng đừng hoảng loạn quá mức: lỗ hổng tồn tại không có nghĩa tài sản chắc chắn bị đe dọa; máy chủ bị xâm phạm cũng không nhất thiết dẫn đến mất vốn trên chuỗi. Điều thực sự quyết định mức độ rủi ro là kẻ tấn công có thể lấy được những thông tin xác thực nào, các thông tin xác thực này có quyền hạn lớn đến đâu, và dự án có thể cô lập và thu hồi các quyền này nhanh đến mức nào. Đối với các dự án Web3, xây dựng bảo mật không chỉ cần tìm cách ngăn chặn tấn công xảy ra, mà còn phải xem xét: khi một thành phần thực sự bị xâm phạm, có thể giới hạn ảnh hưởng trong phạm vi cục bộ, không để rủi ro lan sang nghiệp vụ cốt lõi và các khâu tài sản hay không.