Bảo mật & xử lý lỗ hổng

Bảo mật trước khi bị khai thác.

Bảo mật: Quét & vá và Gói duy trì bảo mật dành cho doanh nghiệp đang vận hành website hoặc hệ thống nội bộ. AI quét source code, kỹ sư xác nhận từng phát hiện, rồi vá và kiểm thử lại trước khi bàn giao. Vụ PHP2Shell tháng 10/2026 cho thấy một lỗi đã nằm trong PHP hơn 10 năm có thể bị thử khai thác trước cả khi có bản vá, và lỗi cũ tương tự có thể tồn tại ở nhiều công nghệ khác, không riêng PHP.

Báo giá sau một buổi trao đổi ngắn. Không cần gửi source code để bắt đầu nói chuyện.

iplus-scan · ví dụ một lượt chạy
hoàn tất

Sáu công đoạn

  1. ✓Đọc source code
  2. ✓Rà thư viện phụ thuộc
  3. ✓Soát cấu hình và cổng công khai
  4. ✓Kỹ sư rà từng phát hiện
  5. ✓Vá và regression test
  6. ✓Báo cáo xếp theo mức độ

Phát hiện 6

  • Caoapp/Orders/Search.php:88

    Dữ liệu người dùng đi thẳng vào câu truy vấn SQL

    Xử lý Tham số hoá truy vấn, thêm test

  • Nghiêm trọngcomposer.lock · image-lib

    Thư viện xử lý ảnh có lỗ hổng thực thi code từ xa đã công bố

    Xử lý Nâng lên bản đã vá, chạy lại test

  • Trung bìnhDockerfile · PHP 7.4

    Runtime đã hết hỗ trợ, không còn bản vá chính thức

    Xử lý Lên kế hoạch nâng phiên bản

  • Caoadmin.example.com

    Trang quản trị mở thẳng ra internet, lộ IP gốc

    Xử lý Đưa sau Cloudflare/WAF, chỉ cho IP tin cậy

  • Trung bình.env.bak

    Khoá API còn nằm trong lịch sử git

    Xử lý Thu hồi khoá, cấp khoá mới

  • Báo động giảvendor/dev-tools

    Hàm eval() nằm trong thư viện test, không chạm production

    Kỹ sư loại bỏ

5 phát hiện thật, 1 báo động giả đã loại trước khi tới tay bạn.ví dụ minh họa

Dữ liệu trên chỉ để minh hoạ cách một lượt quét diễn ra, không phải kết quả của khách hàng nào.

iPlus đang tuyển

iPlus hỗ trợ các doanh nghiệp Việt Nam và Nhật Bản tuyển dụng nhiều vị trí nhân sự AI, với chế độ đãi ngộ cạnh tranh.

Vị trí ưu tiênAI EngineerNagoya/Osaka/Tokyo, Nhật Bản¥4,000,000 – ¥8,000,000 / năm
Bắt đầu miễn phí
Miễn phíTối đa 10 doanh nghiệp mỗi tháng

Kiểm tra nhanh bề mặt website

Chúng tôi kiểm tra website của bạn từ bên ngoài, chỉ bằng phương pháp thụ động, không tấn công, rồi gửi báo cáo về những gì kẻ tấn công cũng đang nhìn thấy.

Trong 3 ngày làm việc

Không ràng buộc. Kết quả thuộc về bạn.

Bạn gửi

  • Tên miền cần kiểm tra
  • Gửi từ một địa chỉ email thuộc chính tên miền đó, để xác nhận bạn là chủ sở hữu

Bạn nhận

  • Báo cáo 1–2 trang
  • Phiên bản phần mềm lộ ra ngoài, đối chiếu với các CVE đã công bố
  • Cấu hình TLS và security header
  • IP gốc có bị lộ hay không, cấu hình SPF/DMARC của email

Bước tiếp theo, nếu phù hợp: Bảo mật: Quét & vá, cho source code và hệ thống bên trong.

Chuyện gì đã xảy ra với PHP2Shell

Lần thử khai thác đầu tiên đến trước bản vá 4 ngày.

PHP2Shell là tên gọi hai lỗ hổng nghiêm trọng (CVE-2026-109618 và CVE-2026-109619, điểm CVSS 4.0 là 9.2) nằm ngay trong lõi PHP. Nguyên nhân là lỗi an toàn bộ nhớ: khi PHP gặp lỗi nghiêm trọng, chẳng hạn hết bộ nhớ giữa lúc xử lý request, dữ liệu dở dang hoặc đã giải phóng có thể bị dùng lại, và kẻ tấn công lợi dụng điều đó để chạy code trên máy chủ mà không cần đăng nhập. Theo W3Techs, 69,2% website xác định được ngôn ngữ phía máy chủ đang chạy PHP.

  1. 2012

    Đoạn code có lỗi đã nằm trong PHP từ bản 5.4.

  2. 2024

    Một lập trình viên PHP thấy dấu hiệu đầu tiên khi xử lý kết quả audit. Chưa ai chứng minh được cách khai thác thực tế, và việc sửa bị treo nhiều tháng vì khó sửa mà không phá tương thích.

  3. 11/08/2026

    Công ty bảo mật Calif báo cáo một lỗi thực thi code từ xa cùng nguyên nhân. Wiz và OpenAI cũng báo cáo thêm các đường tấn công; Wiz cho biết đã dùng mô hình AI tiên tiến. Từ đây đến bản vá là 71 ngày.

  4. 17/10

    Honeypot của Amazon bị thử khai thác, 4 ngày trước khi công bố, lúc chưa có bản vá công khai. Amazon chưa rõ kẻ tấn công lấy thông tin từ đâu.

  5. 20/10

    Khoảng 15:00 UTC, mã CVE bắt đầu lan trên mạng, chưa kèm chi tiết kỹ thuật. Vài giờ sau, một video minh hoạ khai thác bị đăng nhầm.

  6. 21/10, sáng

    Hơn 6 tiếng trước giờ phát hành, một nhà phân phối công bố sớm bản build đã vá. Từ đây, ai cũng có thể so sánh để tìm ra chỗ sửa.

  7. 21/10

    Bản vá ra: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Trong ngày, mạng Cloudflare ghi nhận hàng triệu lượt thử.

  8. 21/10

    Cùng ngày, Node.js vá một lỗi có thể dẫn tới thực thi code từ xa (CVE-2026-111497), do một nhóm dùng AI hỗ trợ tìm ra.

“Phân tích có AI hỗ trợ khiến việc biến một bản vá hay một bản cảnh báo lỗ hổng thành exploit hoạt động được trở nên rẻ hơn.”Amazon Threat Intelligence, nhận định về xu hướng sau PHP2Shell (dịch từ nguyên văn tiếng Anh)
Đọc phân tích kỹ thuật đầy đủ trên blog

Số liệu lấy từ bài phân tích PHP2Shell trên blog iPlus và thông báo gốc của PHP Foundation, Amazon và Wiz.

Vì sao không phải chuyện của riêng PHP

Lỗi cũ, nhưng giá để khai thác đã rẻ đi nhiều.

PHP2Shell không phải loại lỗi hiếm. Điều thay đổi là công cụ. Cùng áp lực này sẽ đến với mọi thành phần gần dữ liệu không tin cậy: runtime ngôn ngữ, thư viện nén và ảnh, web server, firmware.

01

AI biến lỗi “quá khó khai thác” thành lỗi khai thác được

Năm 2024, lỗi này chỉ dừng ở giả thuyết vì không ai chứng minh được cách khai thác. Năm 2026, Wiz dùng mô hình AI tiên tiến để dựng exploit chạy được trên WordPress, Drupal và Joomla, và viết rằng một nhà nghiên cứu hoàn thành trong một tuần việc trước đây cần cả đội hàng đầu nhiều tháng.

02

Khi thông tin kỹ thuật lộ ra, thời gian phản ứng rất ngắn

Sau khi bản vá ra, proof-of-concept mới xuất hiện trong vài giờ. Amazon nhận định AI khiến việc biến bản vá hay thông báo bảo mật thành exploit rẻ hơn, nên nhiều nhóm hơn có thể ra tay sớm hơn. Đây là nhận định về xu hướng: chưa có nguồn nào xác nhận kẻ tấn công trong vụ này đã dùng AI. Dù vậy, quy trình vá theo chu kỳ 7 hay 30 ngày đang giả định một độ trễ không còn nữa.

03

Cùng ngày, một công nghệ khác cũng bị gọi tên

Node.js vá CVE-2026-111497 đúng ngày 21/10. Nhóm bảo mật PHP cho biết họ đã công bố 15 CVE từ ngày 1/7 và xử lý hơn 100 báo cáo không hợp lệ, vì AI làm số báo cáo tăng vọt. Những lỗi cũ từng bị bỏ qua vì “quá khó khai thác” đang được xem xét lại.

Không có cách vá vĩnh viễn cho một thế giới mà việc tìm lỗi và biến lỗi thành công cụ tấn công ngày càng rẻ. Chỉ có vòng lặp nhanh hơn: biết mình đang chạy gì, vá trong vài giờ, giả định đã có người xâm nhập, theo dõi theo thời gian thực, và dùng chính loại AI mà kẻ tấn công sẽ dùng để rà source code của mình trước.

Chúng tôi làm gì

Sáu bước, mỗi bước có một sản phẩm bàn giao cụ thể.

Máy làm phần cần tốc độ và độ phủ. Kỹ sư làm phần cần phán đoán. Mỗi bước kết thúc bằng một sản phẩm cụ thể, không phải lời hứa.

Công cụ chínhClaude CodeCloudflare WAF
  1. 01

    AI quét source code và thư viện phụ thuộc

    AI đọc source code và danh sách thư viện của bạn để tìm lỗ hổng. Kỹ sư đọc lại từng phát hiện, loại báo động giả, và chấm mức độ theo ảnh hưởng thật lên hệ thống của bạn.

    Bạn nhận đượcBáo cáo phát hiện, xếp theo mức độ nghiêm trọng
  2. 02

    Vá lỗi

    Sửa từng lỗ hổng đã xác nhận, ưu tiên mục nghiêm trọng trước. Thay đổi nhỏ, tách riêng để đội của bạn đọc và duyệt được.

    Bạn nhận đượcSource code đã vá, gửi dưới dạng pull request
  3. 03

    Regression test

    Chạy lại các luồng quan trọng để bản vá không làm hỏng chỗ khác. Chỗ chưa có test, chúng tôi viết bổ sung cho vùng vừa sửa.

    Bạn nhận đượcBáo cáo regression test
  4. 04

    Nâng cấp phiên bản, gia cố cấu hình

    Nâng runtime và thư viện lên bản còn được hỗ trợ, đóng các cổng và quyền không cần thiết, thu hồi khoá bị lộ.

    Bạn nhận đượcNhật ký nâng cấp và danh sách cấu hình đã đổi
  5. 05

    Ẩn IP gốc sau Cloudflare/WAF

    Đưa hệ thống ra sau lớp WAF để chặn các đợt tấn công trực diện và giấu địa chỉ thật của máy chủ. Đây là một lớp giảm rủi ro, không thay cho việc vá.

    Bạn nhận đượcCấu hình WAF và DNS đã dựng, tài liệu bàn giao
  6. 06

    Gói duy trì bảo mật

    Khi có lỗ hổng mới, chúng tôi kiểm tra hệ thống của doanh nghiệp có bị ảnh hưởng không trước khi bạn kịp hỏi, rồi vá. Chi tiết ở phần tiếp theo.

    Bạn nhận đượcCảnh báo, báo cáo hằng tháng, kênh liên lạc riêng
Hai cách bắt đầu

Một lần để biết hiện trạng, hoặc duy trì đều đặn.

Hầu hết khách bắt đầu bằng gói một lần để biết mình đang đứng ở đâu. Phạm vi và báo giá được chốt sau một buổi trao đổi ngắn.

Điểm bắt đầu

Quét & vá

Một lần, có điểm đầu và điểm cuối rõ ràng. Phù hợp khi bạn muốn biết hiện trạng và dọn sạch những gì nghiêm trọng nhất.

Bạn nhận được

  • Báo cáo phát hiện, xếp theo mức độ nghiêm trọng
  • Source code đã vá, gửi dưới dạng pull request
  • Báo cáo regression test
  • Nhật ký nâng cấp phiên bản và cấu hình
  • Cấu hình WAF và DNS để ẩn IP gốc

Sau khi xong, hệ thống sạch ở thời điểm bàn giao. Lỗ hổng công bố về sau cần gói duy trì bảo mật hoặc một lượt quét mới.

Phù hợp khi

  • Bạn chưa biết hệ thống mình đang ở mức nào
  • Vừa có tin lỗ hổng mới trong công nghệ bạn đang dùng
  • Muốn dọn sạch những điểm nặng nhất trước khi đối tác hay khách hàng hỏi tới
Đều đặn

Gói duy trì bảo mật

Máy canh liên tục, người vào cuộc khi cần. Chúng tôi tách bạch hai phần này để bạn biết chính xác ai làm gì.

Máy, 24/7

  • WAF chặn tấn công trực diện
  • Cảnh báo khi có bất thường
  • Theo dõi thông báo lỗ hổng của runtime và thư viện bạn đang dùng

Người, theo cam kết

  • Sự cố nghiêm trọng: kỹ sư bắt đầu xử lý trong 4 giờ, kể cả đêm, cuối tuần và ngày lễ
  • Yêu cầu thông thường: xử lý vào ngày làm việc kế tiếp, theo lịch làm việc ghi trong hợp đồng
  • Kênh liên lạc riêng: Slack, LINE, Zalo hoặc điện thoại
  • Báo cáo hằng tháng: đã chặn gì, đã vá gì, còn tồn gì
Hệ thống nào cũng có thể có lỗ hổng tương tự

Không chỉ PHP. Cả những hệ thống cũ không còn ai phụ trách.

Các công nghệ chúng tôi làm việc hằng ngày, và cả những hệ thống đã chạy nhiều năm mà người viết ra nó đã rời đi.

PHP · Laravel · WordPressKể cả plugin và theme
Node.jsExpress, Next.js, thư viện npm
PythonDjango, FastAPI, pip
JavaSpring, Maven, Gradle
.NETASP.NET, NuGet
Hệ thống cũKhông ai bảo trì, tài liệu thiếu

Hệ thống cũ không ai bảo trì

Đây thường là nơi rủi ro lớn nhất và cũng ít ai muốn can thiệp. Chúng tôi bắt đầu bằng việc vẽ lại bức tranh: hệ thống chạy gì, mở ra đâu, phụ thuộc vào đâu. Sau đó mới vá, và chặn từ bên ngoài bằng WAF khi chưa thể nâng cấp.

Những việc chúng tôi không làm

  • Không cấp chứng nhận pentest hay kiểm thử xâm nhập độc lập.
  • Không làm kiểm toán tuân thủ (ISO 27001, PCI DSS, v.v.).
  • Không điều tra pháp y số hay hỗ trợ tố tụng.
  • Không thay SOC, EDR hay bảo mật máy trạm của công ty bạn.
  • Không cam kết hệ thống “không bao giờ bị tấn công”. Không ai cam kết được điều đó.

Nếu bạn cần chứng nhận, hãy dùng một đơn vị độc lập. Chúng tôi vá những gì họ tìm ra.

Câu hỏi thường gặp

Những câu hỏi thường gặp trước khi bắt đầu.

Chúng tôi có phải đưa source code cho các bạn không?
Để quét source code thì có, chúng tôi cần đọc được source code. Bạn chỉ cần cấp quyền chỉ đọc vào repository, không cần quyền vào môi trường production. Nếu chưa thể chia sẻ source code, chúng tôi vẫn rà được cấu hình và bề mặt công khai ở mức hạn chế, và sẽ nói rõ phần nào chưa kiểm tra được.
Việc vá có làm hệ thống ngừng hoạt động không?
Quét không chạm vào production. Bản vá được làm và test trên branch riêng hoặc môi trường staging, rồi triển khai vào thời điểm bạn chọn. Đưa hệ thống ra sau Cloudflare thường không cần dừng dịch vụ. Một số thay đổi như nâng phiên bản lớn có thể cần một khung bảo trì ngắn, và chúng tôi báo trước.
Nếu ngày mai có lỗ hổng mới được công bố thì sao?
Với gói duy trì bảo mật, chúng tôi theo dõi thông báo cho runtime và thư viện bạn đang dùng, kiểm tra hệ thống của bạn có bị ảnh hưởng không và báo lại. Sự cố nghiêm trọng được kỹ sư phản hồi trong 4 giờ, kể cả đêm và cuối tuần. Nếu bạn chỉ dùng gói Quét & vá một lần, hệ thống sạch ở thời điểm bàn giao, còn lỗ hổng công bố về sau cần gói duy trì bảo mật hoặc một lượt quét mới.
Thế nào là sự cố nghiêm trọng, và 4 giờ được tính thế nào?
Sự cố nghiêm trọng là khi website hoặc hệ thống ngừng hoạt động hay bị thay đổi nội dung do tấn công, khi một lỗ hổng đang bị khai thác trên hệ thống của bạn, hoặc khi có dấu hiệu lộ dữ liệu hay mã độc. 4 giờ được tính từ lúc cảnh báo được gửi tới hoặc bạn báo qua kênh liên lạc riêng, đến lúc kỹ sư bắt đầu xử lý: chặn tấn công, cô lập phần bị ảnh hưởng và khôi phục dịch vụ.
Các bạn có thay đội phát triển của chúng tôi không?
Không. Chúng tôi làm việc cạnh đội của bạn. Bản vá được gửi dưới dạng pull request nhỏ, tách riêng, để đội bạn đọc và duyệt. Nếu bạn muốn, chúng tôi có thể hỗ trợ cả việc merge.
Source code của chúng tôi được bảo mật thế nào? Có ký NDA không?
Có. NDA được ký trước khi bạn chia sẻ bất kỳ source code hay dữ liệu nào, hoặc ngay trước buổi trao đổi đầu tiên nếu bạn muốn. Quyền truy cập chỉ đọc, giới hạn theo dự án và thu hồi khi xong việc. Chúng tôi cũng nói rõ công cụ AI nào sẽ đọc source code của bạn và chỉ dùng sau khi bạn đồng ý bằng văn bản. Bản vá được gửi thẳng vào repository của bạn dưới dạng pull request, nên mọi thay đổi trong source code đều thuộc về bạn.
Ẩn IP sau Cloudflare thì đã đủ chưa?
Chưa đủ. WAF chặn được nhiều đợt tấn công trực diện và giấu địa chỉ thật của máy chủ, nhưng nó giảm rủi ro chứ không thay cho việc vá. Một số kiểu tấn công đi qua được lớp này nếu lỗi vẫn còn trong source code. Vì vậy chúng tôi vá trước, dựng WAF làm lớp thứ hai.
Các bạn có cấp chứng nhận pentest hay làm kiểm toán tuân thủ không?
Không. Chúng tôi tìm và vá lỗ hổng, gia cố hệ thống và giảm thiệt hại nếu bị tấn công. Chúng tôi không cấp chứng nhận pentest, không làm kiểm toán ISO 27001 hay PCI DSS. Nếu bạn cần các chứng nhận đó, hãy dùng đơn vị độc lập. Chúng tôi sẵn sàng xử lý những phát hiện họ nêu ra.
Bắt đầu từ đâu

Nắm hiện trạng bảo mật trước khi kẻ tấn công nắm được.

Hãy cho chúng tôi biết hệ thống bạn đang vận hành. Sau một buổi trao đổi ngắn, bạn nhận được phạm vi và báo giá cho lượt quét đầu tiên.