Từ ngày 11/9/2026, điều 14 của Cyber Resilience Act (CRA) — luật an ninh mạng của EU — chính thức có hiệu lực. Nếu bạn là tác giả plugin WordPress có bản premium, hay maintainer plugin mã nguồn mở cho một công ty, bạn nằm trong diện phải tuân thủ: báo cáo lỗ hổng đang bị khai thác lên nền tảng EU trong vòng 24 giờ. Mình đã đọc kỹ văn bản và bài công bố của Patchstack, và tin rằng đây là mốc thời gian mà mọi developer WordPress ở châu Âu cũng như bán hàng sang châu Âu cần nắm ngay hôm nay.
CRA Article 14 là gì và vì sao developer WordPress cần quan tâm?
Article 14 là nghĩa vụ báo cáo bắt buộc trong Cyber Resilience Act. Từ 11/9/2026, nhà sản xuất phần mềm phải báo cáo lên nền tảng chung của EU hai loại sự kiện: lỗ hổng đang bị khai thác thực tế (actively exploited vulnerability) và sự cố bảo mật nghiêm trọng (severe security incident). Điều đáng chú ý: luật áp dụng cả với sản phẩm đã tung ra thị trường châu Âu trước ngày 11/9/2026, không phải chỉ hàng mới.
Với hệ sinh thái WordPress, điều này ảnh hưởng trực tiếp. Mình lấy ví dụ quen thuộc: một plugin WordPress bản GPL có kèm bản premium hoặc bất kỳ hình thức kiếm tiền nào thì người bán được xem là manufacturer — chịu đủ nghĩa vụ, kể cả bị phạt. Một plugin hoàn toàn miễn phí nhưng do nhân viên một pháp nhân duy trì thì được xem là open-source steward — vẫn phải báo cáo, nhưng không bị phạt tiền, thay vào đó EU có quyền dùng biện pháp khác để gỡ sản phẩm khỏi thị trường châu Âu.
Báo cáo gì và trong bao lâu sau khi phát hiện lỗ hổng?
Mỗi lần phát hiện lỗ hổng đang bị khai thác hoặc sự cố nghiêm trọng, bạn phải nộp ba mẫu đơn với ba mốc thời gian khác nhau. Đó là cấu trúc “ba nốt” của Article 14, và mốc đầu tiên rất gấp.
- Cảnh báo sớm (early warning): trong vòng 24 giờ kể từ lúc biết về lỗ hổng đang bị khai thác hoặc sự cố nghiêm trọng.
- Thông báo đầy đủ (notification): trong vòng 72 giờ, kèm thông tin chung và đánh giá ban đầu.
- Báo cáo cuối cùng (final report): với lỗ hổng đang bị khai thác, chậm nhất 14 ngày sau khi có bản vá; với sự cố nghiêm trọng, trong vòng 1 tháng sau thông báo 72 giờ.
Bên cạnh đó, bạn còn phải thông báo cho người dùng đang bị ảnh hưởng về sự cố và cách tự bảo vệ. Nghĩa là ngoài việc vá plugin, bạn cần một kịch bản truyền thông sẵn sàng — chủ đề mình đã từng bàn trong bài về quy trình kiểm tra bảo mật trước khi release plugin.
Cách nộp báo cáo lên nền tảng EU như thế nào?
Toàn bộ báo cáo đi qua Single Reporting Platform (SRP) của EU, tới cơ quan an ninh mạng quốc gia và ENISA. Để dùng SRP bạn cần tài khoản EU Login cá nhân, bật xác thực hai bước (MFA). Đây là phần mình muốn nhấn mạnh: SRP không có API, mỗi báo cáo đòi hỏi điền tay ba mẫu đơn khác nhau. Với hạn 24 giờ của cảnh báo sớm, cách duy nhất khôn ngoan là tạo sẵn tài khoản EU Login ngay bây giờ, đừng đợi đến lúc lỗ hổng nổ ra mới ngồi đăng ký.
Với ai từng phối hợp xử lý CVE, mô hình này giống phiên bản khắt khe hơn của quy trình Patchstack vẫn làm hằng ngày — họ đã phối hợp hơn 50% số lỗ hổng đã biết trong hệ sinh thái WordPress và là một trong những CNA năng động nhất từ trước đến nay.
Patchstack quản lý báo cáo Article 14 thay maintainer ra sao?
Cùng ngày 11/9/2026, Patchstack công bố dịch vụ managed Article 14 reporting miễn phí cho maintainer mã nguồn mở, hoạt động theo ba lớp. Thứ nhất, Patchstack theo dõi tình trạng khai thác thật của từng lỗ hổng, thu thập bằng chứng và chủ động báo cho maintainer khi ngưỡng Article 14 kích hoạt. Thứ hai, Patchstack đứng tên làm Assigned Representative (AR), nộp các mẫu đơn đúng hạn thay maintainer. Thứ ba, họ cung cấp kênh mVDP (mini Vulnerability Disclosure Program) kết hợp bug bounty cho một hoặc nhiều sản phẩm.
Nền tảng mVDP này được xây dựng trong khuôn khổ hợp tác với EU (EIC), đã có hơn 1.000 dự án mã nguồn mở sử dụng. Patchstack là công ty đặt tại EU, chứng nhận ISO 27001, SOC 2 Type 2 và tuân thủ GDPR. Lưu ý nhỏ: dịch vụ hiện miễn phí nhưng có thể thu phí theo từng báo cáo trong tương lai nếu khối lượng lớn mà SRP vẫn không có API.
Checklist 30 phút để developer plugin WordPress chuẩn bị từ hôm nay?
Mình tổng hợp lại thành các bước cụ thể, bạn có thể làm hết trong nửa giờ.
- Tạo tài khoản EU Login cá nhân và bật MFA ngay tại trang của EU, dù bạn chưa cần nộp báo cáo nào. Đây là bước tốn thời gian nhất khi gấp.
- Xác định vai trò pháp lý của bạn: có doanh thu từ plugin (premium, add-on, license) thì bạn là manufacturer; plugin thuần FOSS do pháp nhân duy trì thì bạn là open-source steward. Ghi rõ kết luận này vào tài liệu nội bộ.
- Chuẩn bị mẫu thông báo người dùng: soạn sẵn email thông báo lỗ hổng có các mục mô tả, mức độ, bản vá và cách tự bảo vệ. Khi có chuyện, chỉ cần điền tên CVE.
- Đăng ký mVDP của Patchstack nếu bạn là maintainer mã nguồn mở, để có kênh tiếp nhận report phối hợp và tùy chọn AR quản lý Article 14.
- Rà lại kênh tiếp nhận báo cáo lỗ hổng: kiểm tra security.txt trên website, hộp thư security@, và trang describes quy trình disclosure. Nếu chưa có, bổ sung ngay.
Nếu bạn quản trị site WordPress nhiều plugin thương mại thì cũng nên biết: từ nay plugin bạn dùng có thể bị gỡ khỏi thị trường EU nếu tác giả không tuân thủ. Đây là lý do thêm để ưu tiên plugin từ nhà phát triển có quy trình security nghiêm túc, như mình từng chia sẻ trong bài checklist bảo mật WordPress thời AI bằng WP-CLI.
Kết luận
CRA Article 14 không phải tin tức xa xôi — nó có hiệu lực ngay từ 11/9/2026 và áp dụng cả với sản phẩm đã bán từ trước. Với developer plugin WordPress có hoạt động thương mại, ba mốc 24 giờ, 72 giờ và 14 ngày là con số cần nằm lòng. Việc cần làm ngay thì đơn giản và rẻ: tạo EU Login, xác định vai trò pháp lý, soạn mẫu thông báo. Phần theo dõi khai thác và nộp đơn có thể giao cho dịch vụ như Patchstack, nhưng trách nhiệm cuối cùng vẫn thuộc về bạn. Chuẩn bị từ hôm nay luôn rẻ hơn giải quyết trong 24 giờ hoảng loạn.
