Một dấu chấm phẩy mở cửa GitHub: đọc kỹ CVE-2026-3854 git push RCE

Sáng ra mở mắt, scroll Facebook một chút trước khi dậy hẳn (Brainrot harbit, I know). Bài đầu tiên trên feed là một post từ J2TEAM Security cảnh báo về một CVE mới vừa được công bố.

Git? Wait. Git???

Git là một trong những protocol cũ nhất, nhàm chán nhất, mature nhất mà mọi developer đụng vào hằng ngày. Linus viết bản đầu năm 2005. Hai thập kỷ. Được scrutinize bởi gần như mọi security researcher trên Trái Đất. Mỗi byte trong protocol có lẽ đã có 50 người từng đọc qua.

"RCE critical trong git push"? Are you for real?

Mở laptop, tìm cái writeup gốc của Wiz. Hoá ra đọc kỹ thì bug không nằm trong Git protocol đâu, Git fine. Bug nằm ở cách GitHub xử lý push option ở backend của họ, một component nội bộ tên babeld. Cảm giác shock không vì thế mà giảm đi nhiều, vì payload mà attacker dùng còn shock hơn nữa.

Không phải vì payload phức tạp.

Mà vì nó đơn giản đến mức khó tin: một dấu chấm phẩy.

Cùng một loại bug mà bất kỳ ai từng học SQL injection năm 2005 cũng nhận ra. Cùng một class lỗi mà OWASP Top 10 đã liệt kê trong gần hai thập kỷ. Vẫn xuất hiện trong, đỡ phải nói, một trong những platform được audit kỹ nhất hành tinh, nơi lưu trữ source code của hàng triệu công ty, kho bí mật của ngành công nghiệp phần mềm, và là target săn bug bounty mà mọi researcher đều mơ tới.

Một câu git push với option được crafted khéo. RCE trên backend GitHub.com. Đọc được millions of repositories private và public trên cùng storage node. Chỉ cần là user có push access vào bất kỳ repo nào, nghĩa là về cơ bản, bất kỳ ai có tài khoản GitHub.

Wiz báo cáo cho GitHub vào ngày 4 March 2026. GitHub validate trong 40 phút, deploy fix lên github.com sau khoảng 75 phút nữa, và confirm trong telemetry rằng không có ai exploit ngoài Wiz researchers. Industry phản ứng rất tốt. Nhưng câu chuyện ở đằng sau (vì sao bug này tồn tại, và vì sao GitHub may mắn detect được) là một bài học mà mình nghĩ ai làm internal microservices đều nên ngồi đọc kỹ.

Bài này mình sẽ đi qua từng layer: kiến trúc git push pipeline của GitHub, exact bug ở đâu, ba bước injection cộng hưởng thành RCE, và cuối cùng quay lại một câu hỏi không dễ chịu: nếu bug này có thể tồn tại ở GitHub, thì internal trust trong codebase của bạn đang dựa trên gì?

Cái gì xảy ra

Nói thật ngắn để bạn nắm được stake trước khi mình đi sâu.

Một authenticated user, giả sử ai đó vừa tạo tài khoản GitHub xong, clone một public repo, edit một file vô hại, rồi chạy:

git push -o '<crafted_value>' origin master

Backend GitHub nhận push này, parse option, và do một bug trong cách parse, attacker có thể chèn metadata override các security setting bên trong server. Sau ba bước override, attacker đạt được code execution như user git trên storage node, chính là user sở hữu mọi git repository được host trên node đó.

Wiz xác nhận: git user có filesystem access đến mọi repository (public + private) trên cùng storage node, thuộc bất kỳ tổ chức hay user nào trên platform. Không phải lỗ hổng thông tin nhỏ. Đây là cross-tenant breach scope.

Lỗi được đánh CVSS 8.7, classified CWE-77 (improper neutralization of special elements). 88% GHES instances vẫn vulnerable lúc Wiz public disclosure. Nếu bạn đang chạy GitHub Enterprise Server, đi check version ngay sau khi đọc bài này.

Ba service và một header

Trước khi nói về bug, cần hiểu git push trên GitHub đi qua những gì. Git push không bay thẳng vào storage. Nó đi qua một pipeline ba lớp.

Bạn gõ git push lên repo của mình. SSH connection đến entry point đầu tiên là babeld, một git proxy của GitHub. Babeld nhận connection, gọi sang gitauth để verify credentials và lấy security policy (file size limit, branch protection, commit signing rules…). Sau đó babeld build một header tên là X-Stat, nhồi mọi metadata từ user request vào đó, rồi forward sang gitrpcd, internal RPC server đứng trước storage layer.

Gitrpcd parse X-Stat để biết phải apply security policy nào lên push này, gọi vào pre-receive hook (một Go binary kiểm tra rules cuối cùng), và nếu hook bảo OK thì commit vào storage.

Hai chi tiết về X-Stat cần khắc trong đầu, vì cả bug nằm trong đó:

1. Format: semicolon-delimited key=value pairs. Ví dụ large_blob_rejection_enabled=bool:true;rails_env=production;repo_id=12345;...
2. Parsing semantic: last-write-wins. Nếu cùng một key xuất hiện hai lần, value sau override value trước.

Đây là một design choice rất phổ biến trong internal RPC: simple, fast, không cần JSON overhead. Apache, Nginx, HTTP itself đều có header design dạng tương tự. Cho đến khi bạn nhồi user input vào nó.

Bug: dấu chấm phẩy không escape

Khi user dùng git push -o key=value, push option đó được babeld nhồi vào X-Stat dưới dạng push_option_0=<user_value>. Vấn đề duy nhất, và là trung tâm của toàn bộ câu chuyện này:

babeld không escape ký tự ; trong user value trước khi nhồi vào X-Stat.

Đoạn key của Wiz writeup. "babeld copies git push option values directly into the X-Stat header without sanitizing semicolons." Không phải zero-day exotic. Là CWE-77 cổ điển.

Nhớ: ; là field delimiter của X-Stat. Vậy nếu mình push với option:

git push -o 'x;large_blob_rejection_enabled=bool:false' origin master

Babeld sẽ produce X-Stat header dạng:

X-Stat: ...; large_blob_rejection_enabled=bool:true; ...; push_option_0=x;large_blob_rejection_enabled=bool:false; push_option_count=1; ...

Khi gitrpcd parse header này theo rule split-by-semicolon, kết quả là:

push_option_0              = x
large_blob_rejection_enabled = bool:false   <- INJECTED, override field hợp lệ phía trước
push_option_count          = 1

Last-write-wins parsing biến phần value của user thành một field mới, override field bảo mật mà gitauth set hợp lệ trước đó. Bug ở mức conceptual đơn giản đúng như vậy. Y chang SQL injection. Y chang command injection. Y chang HTTP header smuggling. Một class lỗi 30 năm tuổi, vẫn còn răng.

Disable large_blob_rejection_enabled chỉ là demo. Cho phép push file lớn không phải RCE. Chìa khoá nằm ở chỗ: nếu bạn có thể inject bất kỳ field nào vào X-Stat, thì câu hỏi tiếp theo là: field nào trong X-Stat đủ powerful để dẫn đến code execution?

Chuỗi ba injection: từ inject field đến RCE

Wiz tìm thấy ba field có thể abuse, và quan trọng hơn: chúng compose được với nhau.

Bước 1: rails_env để bypass sandbox

Pre-receive hook trên storage là một Go binary do GitHub viết. Binary này có hai code path khác nhau dựa vào giá trị của rails_env:

• Nếu rails_env=production → chạy hooks trong sandbox restrict, tách biệt khỏi filesystem chính.
• Nếu rails_env là bất cứ giá trị nào khác (development, test, staging, hoặc thậm chí random string) → chạy hooks trực tiếp, full filesystem access, với privilege của git service user.

Logic này có vẻ hợp lý ở thời điểm nó được viết. "Production thì siết, dev thì nới." Đây là pattern Rails idiomatic, mọi Rails developer đều sống với nó. Vấn đề là quyết định về môi trường (sandbox hay không) đã trở thành một decision điều khiển security, và security decision không bao giờ nên dựa trên một string chưa được tin tưởng.

Inject rails_env=development qua semicolon trick. Sandbox biến mất.

Bước 2: custom_hooks_dir để redirect hook lookup

GHES có feature gọi là custom hooks: admin có thể đặt scripts vào /data/user/git-hooks/ để chạy với mỗi push. Pre-receive binary đọc base directory đó từ field custom_hooks_dir trong X-Stat.

Inject custom_hooks_dir=/tmp/attacker_controlled qua chấm phẩy trick. Bây giờ binary tin rằng base dir của hooks nằm ở /tmp/attacker_controlled thay vì path mặc định.

"Nhưng làm sao attacker đặt được file vào /tmp/attacker_controlled?" Họ không cần. Vì còn bước thứ ba.

Bước 3: repo_pre_receive_hooks với path traversal

Trường này định nghĩa danh sách hook scripts mà server sẽ resolve và chạy. Resolve theo logic kinh điển: os.path.join(custom_hooks_dir, hook_name). Cái này gọi là path joining.

Mọi developer Python, Go, Rust từng debug security đều biết một sự thật khó chịu: path.join("/safe/base", "../../../bin/sh") ra /bin/sh. Path traversal là một class lỗi cổ xưa hơn cả semicolon injection.

Inject repo_pre_receive_hooks với entry chứa ../../../../bin/sh (hoặc bất kỳ binary nào trên filesystem). Base dir bị attacker control từ bước 2 cộng với traversal payload từ bước 3, server resolve thành path tới bất kỳ binary nào hệ thống có sẵn, rồi chạy nó với privilege của user git.

/bin/sh là lựa chọn hiển nhiên. Khi pre-receive hook chạy /bin/sh với stdin từ attacker, bạn có shell trên backend GitHub.

Output trên GHES test, theo writeup của Wiz:

remote: uid=500(git) gid=500(git) groups=500(git)

Đó là moment. Không phải kernel exploit, không phải custom CPU side-channel. Một dấu chấm phẩy + một biến môi trường + một path traversal. Ba thứ riêng lẻ vô hại. Cộng lại = remote shell trên GitHub.

Tại sao nó lan đến github.com được

Có một chi tiết tinh tế. Trên GHES, custom hooks bật mặc định vì admin GHES thường cần chúng. Trên github.com, custom hooks không cần thiết, nên có một flag enterprise_mode mặc định set thành false, và pre-receive binary skip toàn bộ code path custom hooks khi flag này off.

Nếu flag đó được set bởi cấu hình server-side và không tới từ X-Stat, đây sẽ là defense layer thứ tư cứu github.com khỏi exploit này.

Nó không. enterprise_mode cũng nằm trong X-Stat. Cũng injectable. Wiz chỉ cần thêm một field nữa vào payload. Và toàn bộ chain hoạt động trên github.com production.

Chỉ một command. Triệu repo cross-tenant. Một trong những platform trị giá nhiều tỷ đô la nhất thế giới.

GitHub may mắn, và đó là vấn đề

Đoạn này là chỗ mình đọc đi đọc lại trong writeup của GitHub.

GitHub Security blog, đoạn họ giải thích vì sao họ tự tin "zero exploitation". Code path "non-production" rails_env không bao giờ được hit trong github.com production, nên mọi telemetry hit đều phải là Wiz.

Nói cách khác: github.com chưa bao giờ chạy với rails_env != production. Vậy bất kỳ request nào trigger code path "non-production-mode" trong pre-receive binary đều là một anomaly. GitHub query telemetry: toàn bộ hits trace về duy nhất một nhóm IP của Wiz researchers. Không có ai khác chạm vào code path đó. GitHub kết luận zero exploitation, không có customer data bị access.

Mình tin GitHub. Họ minh bạch về incident response, fix nhanh, và kết luận của họ có evidence backing.

Nhưng cách họ detect được, bằng anomalous code path, là một loại may mắn không scale.

Nghĩ kỹ một chút: tại sao Wiz researchers lại trigger code path lạ? Vì họ đang test một injection chain cụ thể. Chain đó yêu cầu set rails_env != production để bypass sandbox. Một attacker thật, biết về anomaly detection của GitHub, có thể tìm chain khác không cần đụng vào field đó. Hoặc nếu chain của họ buộc phải đụng, họ sẽ mở ngay nhiều ngàn requests cùng lúc, làm noise quá lớn để forensic tìm được signal.

Detection này dựa trên giả định: "code path đó không bao giờ được hit trong production, nên mọi hit đều là attacker." Giả định này đúng cho riêng exploit của Wiz. Không phải đúng cho mọi exploit có thể có cùng bug.

Tệ hơn nữa: một khi attacker đã có RCE trên storage node, họ có thể tamper với log của node đó luôn. GitHub log access ở HTTP/git protocol layer phía ngoài, đoạn đó nằm trên babeld và gitrpcd, attacker không chạm tới. Nhưng exploit cho phép code execution trực tiếp trên storage dưới quyền user git, và process đó thừa quyền để write/delete bất kỳ log nào được lưu trên cùng filesystem. "No telemetry hits" có thể đơn giản là "no telemetry survived" với một attacker đủ kiên nhẫn.

GitHub không nói dối. Họ thật sự không thấy hit nào ngoài Wiz. Nhưng giả định gốc, rằng telemetry là ground truth, chính nó cũng đang trust một thứ mà attacker đã có quyền touch.

Nói cách khác: GitHub may mắn vì exploit của Wiz force vào telemetry của họ một cách rất nổi bật. Nếu mai có một exploit khác hoặc chain khác trên cùng class bug, họ chưa chắc còn may mắn lần thứ hai.

Câu chuyện thật: Internal trust

OK, mình cần dừng kể bug và quay về thesis của bài.

Bug babeld không escape semicolon là một mistake. Mistake này có thể happen ở bất kỳ codebase nào. Mọi developer đều từng quên escape gì đó. Đó không phải insight mới.

Insight là chỗ này: một mistake duy nhất ở babeld đã cascade qua bốn layer defense và biến thành RCE.

Đếm lại:

1. Babeld có thể sanitize semicolon → không.
2. Gitrpcd có thể re-validate field từ X-Stat trước khi trust → không, gitrpcd treat X-Stat như authoritative.
3. Pre-receive binary có thể hardcode rails_env=production thay vì đọc từ X-Stat (vì nó biết nó đang chạy trên production storage) → không, nó tin field từ peer.
4. Custom hooks có thể require admin-set absolute path không cho phép traversal → không, path joining trust user input.

Bốn layer. Bốn cơ hội để stop chain. Mỗi layer đều có lý do hợp lý cho thiết kế của nó. Babeld trust user input qua git protocol. Gitrpcd trust babeld vì babeld đã làm authentication. Pre-receive binary trust X-Stat vì gitrpcd đã parse và verify. Custom hooks trust path config vì nó đến từ system metadata.

Mỗi layer đều xây trên niềm tin rằng layer ngay trước nó đã làm đúng. Đây là cách hầu hết microservices kiến trúc được build. Đây là pattern bình thường.

Steel-man cho design này: re-validation ở mỗi layer là đắt. Performance hit. Code duplication. Maintenance nightmare. Internal services phải trust nhau ở mức nào đó, nếu không bạn sẽ build distributed system mà mỗi RPC call tốn 50ms chỉ để re-verify dữ liệu mà peer vừa xử lý xong. Netflix làm thế. Uber làm thế. AWS internal services làm thế. Trust giữa internal microservices là design choice rational, được proven qua hai thập kỷ kiến trúc enterprise.

Mình đồng ý, trong thế giới perimeter security. Khi mọi service nằm trong cùng VPC, có firewall vây quanh, attacker không thể chạm vào internal service trực tiếp, thì trust giữa peers là acceptable.

Vấn đề: user input đến tận pre-receive binary. Không phải attacker xuyên perimeter để chạm vào internal service. User push, push option đi thẳng vào X-Stat, X-Stat đi thẳng vào logic security của binary cuối cùng. Boundary giữa "user-controlled" và "internal-trusted" không tồn tại. Nó đã bị babeld pass through cho nguyên một câu của user.

Trong era zero-trust, mọi service phải tự hỏi: "data này có thể bị user touch không?" Nếu có, validate. Không trust delegation. Pre-receive binary đáng lẽ phải hỏi câu này về rails_env, và câu trả lời là yes, vì rails_env đến từ X-Stat, mà X-Stat có chứa fields user-controllable. Không có lý do gì pre-receive binary tin field rails_env không bị tamper.

Bốn layer fail không phải vì developers lười. Fail vì kiến trúc trust đã giả định một boundary không tồn tại.

Một chi tiết về cách Wiz tìm ra bug

Có một điều mình muốn note dù không trực tiếp về kiến trúc, nhưng nó là background quan trọng để hiểu vì sao bug này được phát hiện bây giờ chứ không phải năm năm trước.

Pre-receive hook trên storage là một Go binary precompiled. Nó không có source code public. Để hiểu nó đọc field nào từ X-Stat, làm gì với mỗi field, branching ra sao theo rails_env, bạn phải reverse-engineer disassembled binary. Trước đây, đó là công việc tốn nhiều ngày của một researcher senior, dùng IDA Pro hoặc Ghidra, đọc Go assembly từng function một.

Wiz dùng MCP server cho IDA Pro. Tức là LLM (Claude hoặc GPT) connect được vào IDA, đọc disassembled code, và explain logic của từng function bằng tiếng người. Researcher hỏi "function này xử lý field gì trong X-Stat?", LLM read context từ IDA và trả lời. Trong vài giờ, họ map được hành vi của một binary mà bình thường tốn vài ngày RE thủ công.

Đây không phải "AI tự tìm bug". Bug vẫn cần human intuition để recognize delimiter injection class. Nhưng AI cắt thời gian "hiểu binary" từ days xuống hours, và phía defender chưa kịp recalibrate. Internal binary trên storage của bạn được bảo vệ một phần bởi giả định "không ai có thời gian RE nó". Giả định đó đang chết.

Cứ tưởng tượng 50 nghiên cứu sinh security với mỗi người có một AI co-pilot làm IDA. Số bug được tìm ra trong 12 tháng tới sẽ tăng đột biến, và phần lớn sẽ rơi vào internal binary của các SaaS lớn mà attacker từng coi là blackbox. Đó là một câu chuyện riêng đáng kể, mình sẽ viết kỹ hơn ở bài sau. Trong bài này, đủ để nói: Wiz tìm được bug này nhanh như vậy không phải vì họ thiên tài hơn industry, mà vì tooling vừa qua một inflection point.

Pivot: bug fix trong 75 phút, kiến trúc fix trong nhiều năm

Đây là chỗ làm mình unsettled.

Bug babeld? Fix một dòng code: escape semicolon. GitHub deploy trong 75 phút.

Kiến trúc trust giữa internal services? Không fix một dòng. Cũng không fix một sprint. GitHub viết trong post của họ rằng họ đã "removed unnecessary code paths from production environments that shouldn't have existed", chính là layer defense thứ ba trong list của mình. Đó là patch cho exact chain này. Nhưng pattern gitrpcd trust X-Stat 100% vẫn còn đó. Pattern pre-receive binary đọc rails_env từ peer-supplied header có thể đã fix. Pattern custom_hooks_dir resolve path-joined với user payload cần audit. Mỗi field trong X-Stat đều cần re-evaluate xem có nên trust hay không.

Đó là một engineering project nhiều quý, không phải hot fix.

Và GitHub đã giàu kinh nghiệm, nhiều resource. Mình nhìn quanh, tự hỏi: bao nhiêu công ty có internal RPC dạng X-Stat, peer-trusted, được tạo từ thời perimeter security còn ngự trị, và chưa từng bị audit lại từ góc zero-trust?

Câu trả lời, mình tin: phần lớn.

Nếu bạn build microservices với gRPC + internal-only network, bạn đang sống trên một số phiên bản pattern này. Nếu bạn pass user input qua một internal queue (Kafka, RabbitMQ, SQS) và service downstream consume mà không re-validate, bạn đang sống trên pattern này. Nếu bạn có một service "auth gateway" front của mọi thứ và internal services tin metadata gateway gửi xuống, bạn đang sống trên pattern này.

Câu hỏi không phải "có bug như CVE-2026-3854 trong codebase của bạn không?" Câu hỏi là "khi nào bug tiếp theo?"

Cụ thể cho team của bạn

Đoạn này dành cho ai làm dev/security engineer, không cần đọc nếu bạn chỉ tò mò câu chuyện.

Nếu bạn build internal service nhận data từ peer:

• Mỗi field control execution behavior phải treat như user input. Env var, file path, hook config, feature flag. Kể cả khi nó tới từ một service "internal", "trusted". Question đầu tiên: data này có thể chạm tới user input ở upstream không? Nếu có (kể cả gián tiếp), validate.
• Tránh delimiter-based protocol cho user-controllable data. Nếu bạn vẫn muốn dùng (vì performance), mọi insertion point phải có sanitization explicit, và sanitization phải là default behavior của serialization function chứ không phải optional.
• Production check không nên dựa vào string từ peer. Nếu binary của bạn chạy trên production storage, hardcode is_production = true trong build config. Đừng đọc từ runtime config có thể bị tamper.
• Path joining + user input = path traversal. Mọi lần. Nếu bạn nghĩ "nhưng base dir là constant, traversal sẽ không escape": nó sẽ. Use absolute path validation và allowlist, không phải path joining naïve.
• Audit log nên capture branching của control flow, không chỉ data access. GitHub may mắn vì họ log code path execution. Nếu họ chỉ log data access (như hầu hết audit log), exploit này invisible.

Nếu bạn admin GHES:

• Upgrade ngay. Versions fixed: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0+.
• Grep /var/log/github-audit.log cho push options chứa semicolon. Theo recommendation chính thức của GitHub, bất kỳ push nào có semicolon trong push option là một flag đáng audit, dù bạn đã patch hay chưa.

Trước khi đi panic mode, confirm version đã. Script Python ngắn dưới đây đọc field installed_version từ /api/v3/meta của GHES instance và so với danh sách patched. Không exploit, không gửi payload, chỉ banner check.

#!/usr/bin/env python3
"""Check if a GHES instance is vulnerable to CVE-2026-3854 (banner check, no exploit)."""
import argparse
import json
import ssl
import sys
import urllib.request

FIXED = {
    "3.14": "3.14.25",
    "3.15": "3.15.20",
    "3.16": "3.16.16",
    "3.17": "3.17.13",
    "3.18": "3.18.8",
    "3.19": "3.19.4",
    "3.20": "3.20.0",
}

def vtuple(v):
    return tuple(int(x) for x in v.split(".")[:3])

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("host", help="GHES hostname, e.g. ghe.company.com")
    ap.add_argument("--token", help="PAT if /meta requires auth")
    ap.add_argument("--insecure", action="store_true", help="Skip TLS verify (lab only)")
    args = ap.parse_args()

    req = urllib.request.Request(f"https://{args.host}/api/v3/meta")
    if args.token:
        req.add_header("Authorization", f"Bearer {args.token}")
    ctx = ssl._create_unverified_context() if args.insecure else None

    try:
        with urllib.request.urlopen(req, context=ctx, timeout=10) as r:
            version = json.loads(r.read()).get("installed_version")
    except Exception as e:
        print(f"[!] {args.host}: cannot reach /api/v3/meta ({e})")
        return 2

    if not version:
        print(f"[!] {args.host}: response missing installed_version (maybe github.com, not GHES)")
        return 2

    branch = ".".join(version.split(".")[:2])
    fix = FIXED.get(branch)
    if not fix:
        print(f"[?] {args.host}: unknown branch {branch} (version {version}). Manual review.")
        return 2

    if vtuple(version) < vtuple(fix):
        print(f"[VULNERABLE] {args.host}: version {version}. Fixed in {fix}+. Upgrade now.")
        return 1
    print(f"[OK] {args.host}: version {version} >= {fix}.")
    return 0

if __name__ == "__main__":
    sys.exit(main())

Save thành check_ghes_cve_2026_3854.py, chạy:

python3 check_ghes_cve_2026_3854.py ghe.your-company.com

Exit code: 0 patched, 1 vulnerable, 2 undetermined (unreachable hoặc version không match branch nào trong list). Nếu /api/v3/meta của instance bạn require auth, thêm --token <PAT>. Lab với self-signed cert thì --insecure.

Một caveat thẳng thắn: script này check version banner, không check exploit có chạy được hay không. Nếu version hiển thị OK nhưng instance đã bị tamper từ trước public disclosure, banner có thể cũng đã bị thay đổi. Banner check là first line, không phải last line. Sau khi confirm version, vẫn nên grep audit log theo recommendation phía trên.

Và một câu rộng hơn dành cho admin GHES, cho mọi người trong industry. GitHub release patch cho GHES từ 10/3, public disclosure 28/4. Bảy tuần giữa hai dates đó. Trong bảy tuần ấy, mỗi GHES admin nhận được private notification từ GitHub về CVE critical, kèm patch sẵn sàng deploy. Khi Wiz công bố con số, 88% instance vẫn unpatched.

Đây không phải lỗi của GitHub. Đây là rotting infrastructure pattern của phần lớn enterprise IT: patching tốn time, downtime bị business push back, security là thứ "lo sau Q4". Mỗi CVE critical bạn đọc trên The Hacker News có một con số 88% giấu phía sau, chỉ là không phải lúc nào người ta cũng publish nó. CVE này GitHub publish, và nó nói nhiều về industry hơn là về GitHub.

Nếu bạn ở trong nhóm 88%, đừng đợi public CVE thứ hai mới act. Bug class này (delimiter injection trong internal protocol) gần như chắc chắn còn các variant khác, và những variant đó có thể đã được tìm ra bởi private researchers, đang ngồi đợi một fix bug mới được ship. Bảy tuần là một cửa sổ rất rộng cho ai biết.

FAQ tiếng người:

Đoạn này dành cho ai đọc bài và muốn biết tóm gọn "tôi có sao không?". Không kỹ thuật, đọc trong hai phút.

Tôi dùng github.com bình thường, account và repo của tôi có sao không?

Không. github.com đã được fix trong 75 phút sau khi Wiz báo cáo, từ 4 March 2026. GitHub đã verify telemetry và xác nhận không có ai exploit ngoài Wiz researchers. Repo và account của bạn safe, không cần đổi password hay revoke key gì cả.

Tôi có cần đổi password GitHub hay xoay SSH key không?

Không. CVE này không phải về việc attacker steal credential từ user. Nó cho phép attacker đã có push access (vào bất kỳ repo public nào, kể cả repo họ tự tạo) execute code trên storage node của GitHub. Account của bạn không liên quan trực tiếp đến exploit chain này.

Công ty tôi dùng GitLab self-hosted, có bị ảnh hưởng không?

Không bị bởi CVE-2026-3854 cụ thể, đây là bug GitHub-specific trong code mà GitLab không có. Nhưng GitLab phát hành security advisory riêng hàng tháng (Thứ Năm tuần thứ ba). Hỏi IT xem GitLab đang chạy version gì và có phải latest không. Đó là việc cần làm thường xuyên, không phải việc do CVE này gây ra.

"88% GHES vẫn vulnerable" nghĩa là gì? Liên quan đến tôi không?

GHES = GitHub Enterprise Server, là phiên bản GitHub mà công ty deploy trong hạ tầng nội bộ của họ (thay vì dùng github.com công cộng). 88% admin các instance đó chưa upgrade lúc Wiz công bố. Cách check: nếu URL bạn push code đến là github.com thì không liên quan; nếu là git.tên-công-ty.com hoặc tương tự thì đó là GHES, hỏi IT upgrade ngay.

Bug này có giống SQL injection không?

Đúng cùng class. CWE-77, "improper neutralization of special elements". Pattern giống hệt: user gõ một string, string đó bị nhồi vào nơi nó được parse như cấu trúc (SQL query trong SQL injection, X-Stat header trong CVE này). Ý tưởng cốt lõi y chang. Chỉ khác context. Nếu bạn từng học SQL injection, bạn đã hiểu 80% của bug này.

Tôi không phải security engineer, có cần đọc hết bài này không?

Đoạn về architecture (Ba service + một header, Bug, Chuỗi ba injection) bạn có thể skip nếu không quan tâm chi tiết kỹ thuật. Đoạn quan trọng nhất cho mọi developer là Câu chuyện thật: Internal trust và Cụ thể cho team của bạn. Bài học không phải về git, mà về cách mọi microservices system được build.

Tôi build app web/mobile/backend bình thường, không đụng git infrastructure. Bài này áp dụng cho tôi không?

Có. Bất kỳ ai có internal API, internal queue (Kafka, RabbitMQ, SQS, Redis pub/sub), hoặc nhiều service nói chuyện với nhau qua HTTP/gRPC đều có cùng pattern. Ví dụ cụ thể: nếu user input đi qua một auth gateway, rồi internal service downstream tin metadata gateway gửi xuống mà không re-validate, bạn đang sống trên cùng risk pattern. Validate ở mỗi service, không trust delegation.

Tắt máy

Mình đọc xong cái writeup này, làm cái mình hay làm khi đụng phải security incident lớn: mở terminal, grep codebase mình đang work, tìm chỗ nào trust input từ internal API mà không validate.

Thật, mình tìm được. Nhiều hơn mong muốn. Một vài chỗ là mình tự tay viết.

Đó là điều khó chịu khi đọc một vulnerability writeup chất lượng cao: bạn không bao giờ thoát khỏi nó với cảm giác "GitHub stupid". Bạn thoát ra với cảm giác "ồ, mình cũng có pattern này". Vì pattern này phổ biến. Vì nó là cách microservice architecture được dạy. Vì internal trust là cách hệ thống phân tán scale được.

GitHub may mắn lần này. Wiz là white hat. Disclosure responsible. Detection bằng anomalous code path đủ để confirm zero exploitation. Industry không phải lúc nào cũng có đủ may mắn như vậy.

Mình không có câu trả lời gọn cho câu hỏi "làm sao kiến trúc internal mesh của mình resistant được với bug như thế này". Có thể không có câu trả lời nào là gọn. Chỉ có một chuỗi audit chậm, mỗi field một lần, mỗi service một lần, mỗi trust assumption một lần. Hỏi "field này có thể bị tamper không?" và validate accordingly.

Lần sau khi bạn write một internal RPC handler, hoặc consume một message từ queue, hoặc đọc một header từ peer service, thử dừng lại một giây và hỏi: nếu peer này bị compromised, hoặc nếu peer này pass through user input mà bạn không expect, code này có an toàn không?

Câu trả lời của bạn cho câu đó nói nhiều về kiến trúc hơn bất kỳ ADR nào.

Làm tý mây và không khí sau cơn mưa ở Đà Lạt bạn nhỉ

Bình.