# Một chỗ ship thứ hai, và cửa sổ vá tính bằng giờ

> Ngày 21/10, một platform dừng build/deploy và một bản vá PHP ra đời khi exploit đã lưu hành trước đó. Người tự chạy app hoặc agent trên VM của mình cần hai thứ: một chỗ deploy thứ hai, và một cửa sổ vá tính bằng giờ - kèm checklist và ba lệnh kiểm trạng thái bản vá.

- URL: https://2found.dev/vi/blog/cho-ship-thu-hai-va-cua-so-va-vi/
- Published: 2026-10-22T01:13:10.429Z
- Updated: 2026-10-22T01:13:10.429Z
- Language: vi

---

Ngày 21/10 có hai chuyện xảy ra cách nhau vài giờ. Một platform dừng build và deploy. Và một bản vá bảo mật PHP ra đời trong lúc exploit đã lưu hành từ trước đó, trước cả khi bản vá tồn tại.

Riêng từng chuyện thì bình thường. Đặt cạnh nhau, chúng chỉ về một câu hỏi thực dụng cho người tự chạy app hoặc agent trên VM của mình: không phải "làm sao để không phụ thuộc ai", mà là "tôi có biết mình phụ thuộc ai không, và tôi đã sẵn hai thứ chưa - một chỗ deploy thứ hai, và một cửa sổ vá tính bằng giờ chứ không bằng ngày".

## Ba nguồn nói gì

### Một platform dừng build và deploy

Dennison Bertram kể rằng build và deploy đã bị dừng "từ khoảng 3:24 sáng giờ Eastern", dẫn lại status page, và tới "hơn 3 giờ chiều" thì dashboard và API vẫn được ghi là đang bị ảnh hưởng, không có build mới ở "bất kỳ region nào". Sự cố, theo tên mà trang đó đặt, liệt kê các build bị ảnh hưởng ở US West, EU West, Đông Nam Á và US East. Anh nói rõ mình chỉ đang chép lại status page, và bài được viết khi sự cố còn đang diễn ra.

Điều anh nói là về cách anh dựng hệ thống, không phải về platform. Agent của anh cứ đẩy bản sửa, xin deploy, nhận lỗi, rồi thử lại - vì con agent "được giao đúng một chỗ để deploy, và chỗ đó đóng". Anh có một công cụ deploy mã nguồn mở của riêng mình và đề nghị cấp cho agent đích thứ hai kèm một câu lệnh: "Nếu platform chính đang deploy lỗi và status page của nó ghi có sự cố, thì deploy sang $AH_URL và báo lại là bạn đã làm vậy." Cách anh đặt vấn đề là phần đáng giữ: cần "hai chỗ hỏng vì những lý do khác nhau, chứ không phải một chỗ không bao giờ hỏng".

Một bình luận dưới bài đó, của độc giả tên Oleksandr, chỉ ra một lỗ thật: agent có hai đích vẫn có thể chọn sai, vì "deploy lỗi" không phải bằng chứng platform đang sập. Điều kiện phải là thứ agent kiểm được - cái status page - chứ không phải cái lỗi nó vừa nhận.

### Bản vá PHP ra sau khi exploit đã có

Bài link của Simon Willison, đăng 21/10/2026 lúc 6:41 chiều, mở bằng đúng câu cần đọc: bản cập nhật hôm đó cho toàn bộ dòng PHP 8.x "xử lý hai lỗ thực thi mã từ xa, và đã có exploit lưu hành từ đêm hôm trước, do rò rỉ trong quá trình công bố phối hợp". Dẫn lại PHP Foundation, anh ghi rằng khoảng 15:00 UTC thứ Ba 20/10, hai mã CVE bắt đầu lan trên forum và mạng xã hội, kèm một mốc phát hành sai và một điểm CVSS sai là 10.0 (điểm thật là 9.2); dự án PHP đẩy thông báo trước lên 19:30 UTC và dời ngày phát hành từ 22/10 14:00 UTC sang 21/10 14:00 UTC; và khoảng 20:00 UTC, một trong các công ty bảo mật đã báo lỗi đăng nhầm một video quay cảnh proof of concept chạy được trên một số mục tiêu, mà theo Willison đã "góp phần đẩy nhanh việc phát triển nhiều PoC" trong ngày 21/10. Bài của anh không nêu số CVE và không nêu phiên bản đã vá.

Bài "PHP2Shell Is a PHP Story. It Is Also an AI Story.", đứng tên TruFyre, tóm tắt một công bố của Wiz Research và có thêm mã CVE, phiên bản đã vá theo từng nhánh PHP và một mốc hết hỗ trợ. Chúng tôi không chép lại các con số đó ở đây. Đó là blog của một vendor có CTA bán dịch vụ, bài không nhắc vụ rò rỉ, và chúng tôi chưa đối chiếu được số liệu với advisory của chính dự án PHP. Mã CVE và phiên bản đã vá hãy lấy từ advisory của dự án, đừng lấy từ một bài tóm tắt. Phần AI, như bài này dẫn lại, là khẳng định của vendor rằng model frontier khiến việc tìm lỗ trở nên khả thi cho một nhà nghiên cứu trong khoảng một tuần; hãy đọc nó như lời của vendor.

## Hai chiếc đồng hồ

Chuyện thứ nhất: đồng hồ thuộc về một status page. Chuyện thứ hai: một vụ rò rỉ đưa mã CVE và video PoC ra công khai trước bản vá. "Vá trước, exploit sau" không phải lịch bạn lập kế hoạch được.

Với người tự chạy máy, thứ đáng đo là hai khoảng thời gian: app của bạn không deploy được bao lâu khi đường deploy của người khác đứng, và bạn mất bao lâu để đi từ "cái này ảnh hưởng tới mình" tới "bản đã vá đang là bản web server của mình thật sự chạy". Không khoảng nào về 0 được, cả hai đều đo được, và cái thứ hai thì cắt ngắn được.

## Một chỗ ship thứ hai cần những gì

1. **Hỏng vì lý do khác.** Nhà cung cấp khác, hoặc tối thiểu là account và region khác. Hai service trên một máy là một lần hỏng, không phải hai.
2. **Một lệnh chạy từ laptop, không phải click trên dashboard.** Một script hoặc một CI job đẩy đúng commit đó sang đích thứ hai, và tìm được trong lúc chỗ chính đang sập.
3. **Secret, token deploy và account DNS đọc được mà không cần chỗ chính.** Chỗ tắc thường là cái này, không phải CPU.
4. **DNS đổi được mà không qua nhà cung cấp đang sập,** với TTL đủ ngắn để có nghĩa lúc bạn đổi thật.
5. **Một quyết định về state.** Cái gì không mang đi được - database, volume, file upload - và phần nào chạy không trạng thái ở chỗ thứ hai.
6. **Một lần diễn tập.** Chỗ thứ hai bạn chưa từng deploy lên là kế hoạch, chưa phải năng lực: deploy một lần, bấm giờ, ghi lại số phút.

## Ba việc kiểm trạng thái bản vá

`php -v` là binary CLI, còn web server của bạn có thể đang chạy một nhánh khác. Hỏi package manager và systemd thay vì đoán:

```bash
# đã cài những gói nào (Debian / Ubuntu, rồi RHEL)
dpkg -l | grep -E '^ii +php'
dpkg -s php8.3-fpm | grep -i '^Version'
rpm -qa 'php*'

# có service PHP nào, và khởi động từ khi nào
systemctl list-units --type=service | grep -i php
systemctl status php8.3-fpm

# nâng cấp, rồi restart worker
sudo apt install --only-upgrade php8.3-fpm php8.3-cli
sudo dnf upgrade 'php*'
```

Dòng đáng đọc là `Active: active (running) since ...`: nó cho biết worker đang chạy đúng binary bạn vừa cài, điều mà một chuỗi phiên bản không nói được. Thay `8.3` bằng nhánh bạn dùng; tên unit khác nhau giữa các distro và giữa mod_php với FPM. Nếu app chạy trong container thì kiểm tag và digest của image, bỏ qua host.

## Bản tin này có phải về mình không

1. **Nó nêu đúng thành phần bạn chạy, ở đúng tầng được vá chưa?** "PHP" không phải "một plugin WordPress": hãy đọc advisory nói tầng nào bị ảnh hưởng.
2. **Phiên bản đã vá có nhánh của bạn chưa?** So kết quả ở trên với các phiên bản mà advisory của dự án PHP liệt kê là đã sửa.
3. **Bề mặt đó có mở ra internet không?** Khai thác có cần xác thực hay không làm đổi mức khẩn cấp; advisory nói rõ điều này.
4. **Đã có proof of concept công khai chưa?** Bài của Willison nói exploit đã lưu hành trước ngày phát hành, nên việc này rời khỏi "cửa sổ bảo trì tới" và sang "hôm nay".
5. **Ai đang nói với bạn?** Bài link, bài tóm tắt của vendor và advisory của dự án là ba thứ khác nhau. Số thì lấy từ dự án, trình tự thời gian thì lấy từ người ghi lại sớm nhất.

## Khi cái máy là của bạn

Chạy app trên VM của mình đổi ngay một thứ: không ai xếp lịch bảo trì hộ bạn, nên số giờ trong cửa sổ vá là của bạn, tiêu hay mất là do bạn. Nó không xoá bỏ phụ thuộc, chỉ dời phụ thuộc - sang cái máy, sang người cho bạn thuê cái máy, và sang người đọc advisory.

Nếu bạn đang cân nhắc 2server để chạy app và agent trên VM của mình: [yêu cầu đã công bố](https://2found.dev/facts/2server.md) ghi VM chạy Debian 12/13 hoặc Ubuntu 22.04/24.04, có Python 3, SSH bằng khóa và sudo không cần mật khẩu; bộ nhớ VM nên bắt đầu từ 2 GB, rồi tính theo replicas và memory của từng app, nhân hai vì một lần release chạy cả hai thế hệ, cộng thêm phần các extension. Hãy đo trên máy của bạn như chúng tôi đã đo, [cách làm ở đây](https://2found.dev/vi/blog/giam-cpu-pressure-56-xuong-17-tren-vm-nho/). Ở đây cũng không có lời hứa nào rằng sản phẩm vá PHP hay gói nào khác hộ bạn.

Tuần này: chọn chỗ ship thứ hai và deploy lên đó một lần, bấm giờ; viết câu lệnh agent của bạn theo khi chỗ chính trả lỗi; rồi chạy ba việc kiểm ở trên và ghi lại nhánh PHP bạn đang chạy cùng phiên bản bạn sẽ phải lên.

Một ngày, hai chuyện, hai giả định bị bẻ: đường deploy thì luôn sống, và bản vá thì luôn tới trước exploit. Một chỗ thứ hai bạn đã dùng thật, và ba lệnh bạn đã chạy thật, thì là.

## Nguồn

- Dennison Bertram, "Railway Is Down Today. My Agents Taught Me to Keep a Second Place to Ship.", dev.to, đăng Oct 21 - https://dev.to/dennisonbertram/railway-is-down-today-my-agents-taught-me-to-keep-a-second-place-to-ship-37kd (kèm một bình luận của độc giả "Oleksandr")
- Simon Willison, "Today's PHP Security Release, and How We're Strengthening PHP Security", đăng 21/10/2026 lúc 6:41 chiều - https://simonwillison.net/2026/Oct/21/php-security-release/
- TruFyre, "PHP2Shell Is a PHP Story. It Is Also an AI Story." - https://trufyreai.medium.com/php2shell-is-a-php-story-it-is-also-an-ai-story-5c02641d14ec (đọc bản trên blog của vendor; bản Medium không mở được lúc tôi kiểm)