แพตช์แล้วยังไม่จบ: เช็กและแก้ LiteLLM, GitLab, Python, Java และ pandas ประจำสัปดาห์

นี่คือคู่มือหน้างานของคลิปสายเดฟประจำสัปดาห์ครับ สัปดาห์ 19–26 ตุลาคม 2026 มี 4 เรื่องที่เป็นแพตช์ความปลอดภัย กับอีก 1 เรื่องเป็นข่าวดีที่มีจุดต้องระวัง ประเด็นใหญ่ของสัปดาห์คือ หลายตัวออกรอบสองแล้ว ใครอัปไปตั้งแต่ต้นสัปดาห์ เลขที่ได้อาจยังไม่พอ ผมตรวจเลขเวอร์ชันและขั้นตอนทุกข้อกับประกาศของโครงการหรือผู้ผลิตเมื่อ 27 ตุลาคม 2026 ข้อไหนเป็นความเห็นของผมจะเขียนบอกไว้

คำสั่งในบทความตรวจแค่ไวยากรณ์ shell (bash -n) ไม่ได้รันกับระบบจริง ก่อนใช้กับเครื่อง production ให้อ่านทีละบรรทัดก่อนนะครับ

สรุป 30 วินาที: รุ่นที่ต้องมีตอนนี้

เรื่อง	ใครต้องสนใจ	รุ่น/สิ่งที่ต้องทำตอนนี้
LiteLLM 1.107.0	ใครติดตั้ง LiteLLM หรือใช้ Docker image ของมัน	ถ้าเคยมี 1.107.0 ให้ถือว่าเครื่องนั้นโดนแล้ว สร้างใหม่ ล็อกรุ่นสะอาด (1.106.2 หรือ 1.106.4) แล้วเปลี่ยนกุญแจทุกตัว
GitLab CVE-2026-110264	คนตั้ง GitLab เอง (self-managed)	19.5.1 / 19.4.3 / 19.3.6 (สายเก่ามี 19.2.9, 19.1.9, 19.0.10, 18.11.13)
Python × eMudhra	ทุกคนที่ใช้ Python และ pip	3.15.2 หรือ 3.14.10 และ pip ≥ 26.2.2 ในทุก venv
Oracle Java × eMudhra	คนใช้ Oracle JDK และ OpenJDK ทุกค่าย	Oracle JDK รุ่น .0.3 (เช่น 21.0.13.0.3) หรือ 8u511-b33; .0.2 ยังไม่พอ
pandas 3.1.0	สายข้อมูล	ข่าวดี แต่คอลัมน์รหัสที่อ่านเป็น category จะเสียเลขศูนย์นำหน้า

1. LiteLLM 1.107.0: แพ็กเกจดังฝังตัวขโมยกุญแจ

LiteLLM คือไลบรารีที่ให้โค้ดเราคุยกับผู้ให้บริการ AI ได้กว่าร้อยเจ้าผ่านที่เดียว ตามประกาศของ LiteLLM แพ็กเกจ litellm==1.107.0 ทั้ง 7 ไฟล์บน PyPI ขึ้นอยู่ตั้งแต่ 18:39 ถึง 20:23 น. วันที่ 21 ตุลาคม (เวลาไทย) ส่วน Docker Hub แท็ก v1.107.0, latest, main-latest และ main-stable ชี้ไป image ที่โดนฝังระหว่าง 18:46–21:20 น. ตัวที่ฝังมาคือ cook.pth กับ cook.py ที่กวาดรหัสผ่านและกุญแจ และ sitecustomize.py ที่ดึงโค้ดใหม่มารันทุกชั่วโมง

ที่น่ากลัวคือ แค่เปิด Python ใน environment นั้นก็โดน ไม่ต้อง import litellm เลย เพราะไฟล์ .pth ถูก Python อ่านทุกครั้งที่เริ่มทำงาน เหมือนโน้ตที่แปะไว้หน้าประตูบ้าน ใครเดินเข้าบ้านต้องอ่านทุกครั้ง แล้วโน้ตนั้นสั่งให้ถ่ายรูปกุญแจทุกดอกส่งออกไปข้างนอก

บทวิเคราะห์ต้นเหตุของ LiteLLM (23 ตุลาคม) สรุปว่า master key ที่หลุดในรีโพสาธารณะตั้งแต่ 27 พฤษภาคมไม่เคยถูกเพิกถอน คนร้ายใช้คีย์นั้นเข้าระบบเมื่อ 10 ตุลาคม จนได้โทเคน GitHub CLI ของเจ้าของ org มาใช้ปล่อยรุ่นปลอม

สังเกตยังไง

LiteLLM เตือนว่าการเริ่ม Python ใน environment ที่โดนจะทำให้มัลแวร์ทำงานอีกรอบ รวมถึงตอนรัน pip ด้วย ผมจึงแนะนำให้เช็กจาก shell ด้วยการดูไฟล์ก่อน คำสั่งชุดนี้มาจาก StepSecurity และชื่อไฟล์ตรงกับที่ LiteLLM และ OSV ระบุ:

# ไฟล์ที่มัลแวร์วางไว้ใน site-packages
find / -name cook.pth -path "*site-packages*" 2>/dev/null
find / -type d -name "litellm-1.107.0.dist-info" 2>/dev/null
# ไฟล์ marker ว่าส่งข้อมูลออกไปแล้ว และ lock ของ daemon ที่ค้างอยู่
ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>/dev/null
lsof /tmp/remote_code_loader.lock 2>/dev/null
# lockfile และ requirements ที่เคยล็อก 1.107.0
grep -rniE "litellm[=<>~! ]*1\.107\.0([^0-9rc]|$)" . --include='requirements*.txt' --include='*.lock' --include=pyproject.toml --include='Pipfile*'
# Docker image ที่ดึงมาไว้ในเครื่อง
docker images --digests | grep -E 'berriai/litellm|litellm/litellm'

• เจอไฟล์ใดไฟล์หนึ่ง แปลว่าโดนแน่ แต่ ไม่เจอก็ยังไม่ได้แปลว่าสะอาด เพราะ container และการล้าง /tmp ลบหลักฐานได้ (LiteLLM)
• container ที่เคยรัน image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e ให้ถือว่าโดน
• ดูบันทึกเครือข่ายว่ามีการต่อไปที่ litellm.dev หรือ path /codepy ไหม
• บนคลาวด์ ให้ดู CloudTrail ว่ามี GetCallerIdentity จาก role ของเครื่องช่วงที่ติดตั้ง แล้วมีการใช้ credential ของ role นั้นจากนอกระบบเราหรือเปล่า

แก้ยังไง

ลำดับนี้มาจากประกาศของ LiteLLM:

1. อย่าเริ่มด้วย pip install เพราะเท่ากับเปิด Python ให้มัลแวร์ทำงานอีกรอบ
2. จาก shell ลบ cook.pth, cook.py, sitecustomize.py และไฟล์ __pycache__/cook*.pyc, sitecustomize*.pyc ออกจาก ทุก site-packages ที่โดน
3. ปิด daemon ของ Python ที่ถือ /tmp/remote_code_loader.lock อยู่ (หาด้วย lsof ตามข้างบน)
4. สร้าง venv และ image ใหม่ตั้งแต่ต้นดีกว่าซ่อมของเดิม แล้วล็อกรุ่นให้ชัด LiteLLM แนะนำ litellm==1.106.2 ซึ่งเป็นรุ่นสุดท้ายก่อนเกิดเหตุ ส่วนรุ่นสะอาดล่าสุดตอนนี้คือ 1.106.4 (25 ตุลาคม) หรือ backport 1.105.5, 1.104.7, 1.103.9 สำหรับ image ให้อ้างด้วย digest แทนแท็ก
5. ถ้าเคยติดตั้ง 1.107.0 บนเครื่องที่ออกอินเทอร์เน็ตได้ ให้ถือว่าข้อมูลหลุดไปแล้ว แล้วเปลี่ยนจากเครื่องที่สะอาด: IAM role ของเครื่อง/งาน, กุญแจผู้ให้บริการทุกตัวที่เก็บใน DB ของ LiteLLM proxy, master key และ virtual key, รหัสผ่านใน DATABASE_URL และ secret ทุกตัวที่อยู่ใน environment ของโปรเซสบนเครื่องนั้น
6. ตั้งแต่ 1.106.3 ไป image ทุกตัวเซ็นด้วย cosign key ใหม่จาก commit e82a3c6 key เก่าจะตรวจไม่ผ่าน (LiteLLM v1.106.3) ใครมีสคริปต์หรือ admission policy ที่ตรวจลายเซ็น ต้องอัป key ด้วย

ลูกค้าที่ใช้รุ่น enterprise จากช่องทางแจกส่วนตัวของ LiteLLM ไม่โดนเหตุนี้ รายละเอียดเต็มอยู่ในบทความ LiteLLM

2. GitLab CVE-2026-110264: CVSS 10 คนนอกรันโค้ดได้

ข้อนี้สำหรับคนที่ตั้ง GitLab เองครับ ช่องโหว่คะแนนเต็ม 10 ทำให้คนที่ไม่ได้ล็อกอินรันโค้ดบนเซิร์ฟเวอร์ได้ โดนทุกรุ่นตั้งแต่ 7.0 (GitLab) เอกสารกฎตรวจจับของทีม GitLab Security อธิบายว่าจุดเข้าคือตัวแสดงผลไฟล์ Org-mode (.org) ซึ่งเอาคีย์เวิร์ด #+TODO: ไปสร้าง regex ตรง ๆ ถ้าซ้ำเกิน 32,767 ครั้งตัวนับจะล้นจนเขียนหน่วยความจำนอกขอบเขต และไปจบที่การรันคำสั่งด้วยสิทธิ์ผู้ใช้ git คนร้ายขอแค่มีโปรเจกต์สาธารณะสักโปรเจกต์ไว้วางไฟล์ .org

จุดสังเกตคือ ใครเพิ่งแพตช์รอบ 12 ตุลาคม (ช่องโหว่ CVSS 10 อีกตัว คือ CVE-2026-97229) ยังไม่รอด ต้องอัปอีกรอบ เหมือนเพิ่งปะท่อรั่วไปจุดหนึ่ง แล้วน้ำก็พุ่งออกมาอีกจุดข้าง ๆ

สังเกตยังไง

• เวอร์ชัน: ในหน้าเว็บ GitLab แถบซ้ายด้านล่างเลือก Help → Help เวอร์ชันจะแสดงด้านบนสุด หรือรัน sudo gitlab-rake gitlab:env:info บนเครื่อง (ดูได้จาก /opt/gitlab/version-manifest.txt ด้วย)
• รุ่นที่ปลอดภัย: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 หรือ 18.11.13 (ออก 21 ตุลาคม) GitLab.com แพตช์ให้แล้ว
• ร่องรอย: ทีม GitLab Security ปล่อยกฎตรวจจับ 2 ตัว คือ Onigmo native worker crash และ Org mode render error burst คำสั่งข้างล่างย่อมาจากเอกสารสองฉบับนั้น (path ของ Linux package):

PUMA=/var/log/gitlab/puma/puma_stderr.log
EXC=/var/log/gitlab/gitlab-rails/exceptions_json.log
# worker crash ที่มีร่องรอยของตัวแสดงผล Org-mode
grep -B1 -A20 '\[BUG\]' "$PUMA"* | grep -E 'org-ruby|headline\.rb|regexp_helper\.rb|regexp_matcher\.rb|match_at|onig_search_gpos|onig_compile|compile_tree|compile_length_tree|rb_str_sub_bang'
# client ที่ทำให้ไฟล์ .org render timeout ถี่ ๆ
grep '"exception.class":"Timeout::Error"' "$EXC"* | grep '"extra.class_name":"OtherMarkup"' | grep -E '"extra.file_name":"[^"]*\.org"' | grep -o '"meta.client_id":"[^"]*"' | sort | uniq -c | sort -rn
# ไฟล์ .org ที่มีบรรทัด #+TODO ยาวผิดปกติในรีโพ
rg -l --glob '**/*.org' '^\#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'

GitLab เตือนเองว่าการเจาะที่สำเร็จมัก เงียบและไม่ทำให้ระบบล่ม การไม่เจออะไรจึงไม่ได้แปลว่าปลอดภัย ให้ดูเพิ่มว่ามีไฟล์ของผู้ใช้ git ใน /tmp, โปรเซสลูกแปลก ๆ ของ Puma หรือ Sidekiq, การเชื่อมต่อออกนอก, หรือ crontab และ SSH key ของผู้ใช้ git ถูกแก้หรือไม่

แก้ยังไง

1. อัปเดตทันที เริ่มจากเครื่องที่เปิดออกอินเทอร์เน็ตก่อน ตามที่ CERT-EU แนะนำ บน Debian/Ubuntu ที่ใช้ Linux package เช่น sudo apt update && sudo apt install gitlab-ee=19.5.1-ee.0 (หรือ gitlab-ce=19.5.1-ce.0) ถ้าใช้รุ่นเก่ามากให้ไล่ตาม upgrade path ของ GitLab
2. เผื่อ downtime เครื่อง single-node จะดับระหว่างอัปเพราะต้องรัน migration ให้เสร็จก่อน ส่วน multi-node ที่ทำ zero-downtime upgrade ถูกวิธีจะไม่ดับ
3. สายเก่ารู้ไว้: รุ่น 18.11.13 ถึง 19.2.9 ได้แค่แพตช์ตัว CVSS 10 อีก 11 ช่องโหว่ในรอบเดียวกัน รวม 2 ตัวระดับสูง (CVE-2026-15723 และ CVE-2026-112212) แก้เฉพาะใน 19.3.6, 19.4.3 และ 19.5.1 (GitLab)
4. ระหว่างยังอัปไม่ได้ GitLab แนะนำให้ลดการเปิดโปรเจกต์เป็นสาธารณะเท่าที่ทำได้ และเช็กว่าเก็บ puma_stderr.log ไว้จริง
5. ถ้าเจอว่ามีการรันโค้ด ให้ถือว่าเครื่องโดนแล้ว: เปลี่ยน secret ใน gitlab-secrets.json, ตัวแปร CI/CD ทุกตัว, runner token และ access token ทั้งหมด บล็อก IP ต้นทาง ปิดหรือลบโปรเจกต์ที่มีไฟล์ .org อันตรายพร้อม commit นั้น และเก็บ log ไว้ก่อนรีสตาร์ต

ณ วันที่ตรวจ ข้อมูลในระเบียน CVE ที่ CISA เติมไว้ยังระบุว่าไม่พบการโจมตีจริง และยังไม่อยู่ในรายการ KEV แต่ช่องนี้ใช้อัตโนมัติได้และไม่ต้องล็อกอิน อย่ารอครับ รายละเอียดเต็มอยู่ในบทความ GitLab

3. Python กับใบรับรอง eMudhra: อัปสองรอบในสัปดาห์เดียว

ต้นเรื่องคือกุญแจของ CA ตัวกลางของ eMudhra (ผู้ออกใบรับรอง HTTPS รายหนึ่ง) หลุด ทำให้คนที่อยู่กลางทางปลอมตัวเป็นเว็บอื่นได้ รวมถึง pypi.org และ python.org (PSF Discourse) เทียบง่าย ๆ คือบริษัทรับทำบัตรพนักงานเจ้าหนึ่งทำแม่พิมพ์หาย ใครเจอแม่พิมพ์ก็ทำบัตรปลอมที่ดูเหมือนจริงได้ ทางแก้จึงต้องบอกทุกเครื่องว่า “บัตรจากแม่พิมพ์นี้ ห้ามเชื่อ”

• รอบแรก (21 ตุลาคม): Python 3.15.1, 3.14.9 และ 3.13.17 มาพร้อม pip 26.2.2 ที่ใช้ certifi 2026.10.19
• รอบสอง (25 ตุลาคม): ใส่รายชื่อกุญแจที่ห้ามเชื่อไว้ในโมดูล ssl เลย (CVE-2026-115557) ทำให้แม้ pip ยังเป็นรุ่นเก่า การใช้ pip ตามปกติก็ปลอดภัยจากการโจมตีด้วยกุญแจชุดนี้ (Python Insider)

สาย	รุ่นที่ควรมีตอนนี้	หมายเหตุ
3.15	3.15.2	มีตัวติดตั้ง macOS/Windows
3.14	3.14.10	มีตัวติดตั้ง
3.13	3.13.18	source เท่านั้น
3.12	3.12.16	source เท่านั้น
3.11	3.11.18	source เท่านั้น

Python 3.10 ลงไปหมดอายุแล้ว ไม่ได้แพตช์นี้

สังเกตยังไง

python3 -VV                                             # ต้องเป็นรุ่นในตารางขึ้นไป
python3 -m pip --version                                # ต้อง ≥ 26.2.2 (รันในทุก venv)
python3 -c "import certifi; print(certifi.__version__)" # ต้อง ≥ 2026.10.19
uv --version                                            # ต้อง ≥ 0.13.4

PSF ระบุรุ่นขั้นต่ำของแพ็กเกจที่เกี่ยวข้องไว้ดังนี้: certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, conda 26.9.4, pixi 0.82.1 และ virtualenv 21.14.12 ตอนนี้ certifi ล่าสุดคือ 2026.10.23 และ uv ล่าสุดคือ 0.13.6

แก้ยังไง

1. ในแต่ละ environment อัป pip ด้วยคำสั่งที่ PSF ให้ ซึ่งระบุไฟล์พร้อมค่า SHA-256 (คัดลอกให้ครบทั้งบรรทัด):

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
python -m pip install --upgrade certifi

2. ใช้ pip ตัวใหม่นั้นอัป certifi และ uv ต่อ จากนั้นติดตั้ง Python รอบสอง: 3.15.2 หรือ 3.14.10 (มีตัวติดตั้ง) หรือ build 3.13.18, 3.12.16, 3.11.18 จาก source
3. คนใช้ uv: อัป uv เป็น 0.13.6 ขึ้นไป แล้วรัน uv python upgrade (uv 0.13.6 เพิ่ม build ของรอบสองแล้ว) venv ที่ล็อกเลข patch ไว้จะไม่สลับ interpreter ให้เอง และต้องอัป pip ใน venv เดิมแยกอีกที
4. Docker image ให้ build ใหม่โดยปิด layer cache (เช่น docker build --no-cache) เพื่อให้ได้ใบรับรองของระบบชุดล่าสุด
5. ใครยังใช้ 3.9 หรือ 3.10 ให้วางแผนย้ายออก เพราะ pip ที่แถมมายังเชื่อ root ของ eMudhra/emSign อยู่ (uv 0.13.5)

ช่องว่างที่ต้องรู้: คนที่ต้องอยู่บน 3.13 ใน Windows หรือ macOS ไม่มีตัวติดตั้งของ 3.13.18 ตัวติดตั้งล่าสุดคือ 3.13.17 ซึ่งมี pip 26.2.2 แต่ไม่มีการบล็อกในโมดูล ssl ของรอบสอง รายละเอียดเต็มอยู่ในบทความ Python

4. Oracle Java: เรื่องเดียวกับ Python และ .0.2 ยังไม่พอ

เรื่อง eMudhra เดียวกันนี้ไปโผล่ฝั่ง Java ด้วยครับ Oracle ออกประกาศฉุกเฉินสองฉบับ ทั้งคู่เป็นส่วน JSSE (ส่วนที่ทำ HTTPS/TLS ของ Java) คะแนน 9.1 โจมตีผ่านเครือข่ายได้โดยไม่ต้องยืนยันตัวตน

• ฉบับแรก CVE-2026-91403 (21 ตุลาคม): รุ่น .0.2 เลิกเชื่อ CA ตัวกลางของ eMudhra 8 ใบ และใบที่ Sectigo เซ็นข้ามอีก 8 ใบ โดยเพิ่มไว้ในไฟล์ lib/security/blocked.certs
• ฉบับสอง CVE-2026-114820 (24 ตุลาคม): รุ่น .0.3 ถอด root CA ที่เกี่ยวข้อง 4 ใบออกจาก cacerts และทำให้รุ่น .0.2 กลายเป็นรุ่นที่โดนเอง

สาย Oracle JDK	รุ่นที่ควรมีตอนนี้
27	27.0.1.0.3
25	25.0.5.0.3
21	21.0.13.0.3
17	17.0.21.0.3
11	11.0.33.0.3
8	8u511-b33

เลขชุดนี้ตรงกับบันทึกรุ่นของ Oracle ส่วน GraalVM ผมยังยืนยันเลขรุ่นแก้ไม่ได้

สังเกตยังไง

java -version                                                       # ดูทั้งเลขรุ่นเต็มและชื่อผู้ผลิต
keytool -list -cacerts -storepass changeit | grep -iE 'emsign|comodoaaa'
java CheckCerts.java                                                 # ตัวตรวจของ OpenJDK

• ตัวตรวจ CheckCerts.java ของ OpenJDK ใช้ได้กับ JDK 8 ขึ้นไปทุกค่าย ถ้ายังเชื่อ root ที่มีปัญหาอยู่จะพิมพ์ “BAD ROOT” ถ้าไม่มีจะพิมพ์ “No bad root certificates found” การรันแบบไฟล์เดียวด้วย java CheckCerts.java ใช้ได้บน JDK 11 ขึ้นไป (ข้อนี้ผมอนุมานเอง) ส่วน JDK 8 ต้อง javac ก่อน
• ชื่อ alias ใน cacerts ต่างกันตามผู้ผลิต บน Temurin จะยาวกว่าของ Oracle จึงต้อง list ดูชื่อจริงก่อนจะลบอะไร
• JAR ที่เซ็นด้วยสายใบรับรองที่โดน จะตรวจไม่ผ่านด้วย jarsigner -verify -strict

แก้ยังไง

1. Oracle JDK: ติดตั้งรุ่น .0.3 ตามตาราง (Java 8 ใช้ 8u511-b33) ถึงจะเพิ่งอัป .0.2 ไปเมื่อต้นสัปดาห์ก็ต้องอัปอีกรอบ Oracle ระบุว่ารอบแพตช์ปกติถัดไปคือ 17 พฤศจิกายน 2026
2. OpenJDK ค่ายอื่น (Temurin, Corretto, Zulu ฯลฯ): ตามคำแนะนำของ OpenJDK ทางที่ดีที่สุดคืออัป runtime เป็นรุ่นที่บันทึกรุ่นระบุว่าแก้ JDK-8395690 / CVE-2026-114820 ถ้ายังอัปไม่ได้ ให้สำรองไฟล์ cacerts แล้วลบ root 4 ใบด้วย keytool -delete (ใช้ชื่อ alias จริงที่ list ได้) หรือเปิดการตรวจใบรับรองที่ถูกเพิกถอนด้วย -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true แล้วรีสตาร์ตทุกโปรเซส Java
3. OpenJDK ที่มากับ Debian/Ubuntu: ต้องสร้าง trust store ใหม่เอง:

sudo rm -f /etc/ssl/certs/java/cacerts
sudo update-ca-certificates --fresh

ส่วน Fedora, RHEL, Oracle Linux, Arch และ Gentoo อัปใบรับรองของระบบก็น่าจะพอ (ตามถ้อยคำของ OpenJDK) Homebrew และ FreeBSD ไม่ได้ใช้ใบรับรองของระบบ ให้อัปแพ็กเกจ JDK ตรง ๆ

4. ไลเซนส์: Oracle JDK 21 ตั้งแต่ 21.0.13 ขึ้นไปใช้ไลเซนส์ OTN ที่ต่างจากเดิมมาก ใช้ฟรีได้บางแบบ เช่น ส่วนตัวและพัฒนา งาน production ให้ฝ่ายที่ดูแลสิทธิ์ซอฟต์แวร์ตรวจก่อนดาวน์โหลด

รายละเอียดเต็มอยู่ในบทความ Oracle Java

5. pandas 3.1.0: ข่าวดี แต่เช็กเลขศูนย์นำหน้าก่อนอัป

ปิดท้ายด้วยข่าวดีครับ pandas 3.1.0 ออกเมื่อ 22 ตุลาคม มี DataFrame.select() ใหม่ filter() รับเงื่อนไขผ่าน cond= ได้ และ read_csv() เร็วขึ้น ทีม pandas บอกว่าการอ่านแบบเธรดเดียวมักเร็วกว่า 3.0 ราว 2–3 เท่า ถ้าไฟล์อยู่ในเครื่อง ไม่บีบอัด ใหญ่ตั้งแต่ 5 MB และไม่ได้ใช้ตัวเลือกที่ต้องอ่านทั้งไฟล์ในรอบเดียว ก็อ่านแบบขนานได้อีก ค่า mode.max_threads ตั้งต้นเท่าจำนวน CPU แต่ไม่เกิน 6

สังเกตยังไง (จุดที่ต้องระวัง)

• คอลัมน์รหัสที่อ่านด้วย dtype="category": 3.1.0 ให้ทุก engine เดาหมวดเป็นตัวเลขหรือ boolean ได้ คอลัมน์อย่างรหัสไปรษณีย์หรือเลขบัญชีที่มีศูนย์นำหน้าจึงกลายเป็นหมวดตัวเลข เลขศูนย์ข้างหน้าหายไป แบบเดียวกับตอนอ่านโดยไม่ใส่ dtype="category" (ซึ่งหายมาตั้งแต่ก่อน 3.1.0 แล้ว)
• numexpr 2.14.1: pandas เลิกใช้รุ่นนี้เร่งการคำนวณแล้ว เพราะบาง build คืนค่าผิดแบบเงียบ ๆ เช่น ได้คอลัมน์เป็นศูนย์ทั้งหมด ให้ใช้ 2.14.2 ขึ้นไป
• filter() ที่ส่ง list ของ True/False ตามตำแหน่ง: ตอนนี้ขึ้น UserWarning ให้เปลี่ยนไปใช้ cond= (กรองด้วยเงื่อนไข) หรือ items= (เลือกตามชื่อ)

แก้ยังไง

1. อ่านคอลัมน์รหัสเป็นสตริงก่อน แล้วค่อยแปลงเป็น category ตามที่ whatsnew แนะนำ โค้ดข้างล่างเป็นตัวอย่างบางส่วนที่ผมเขียนเองแบบระบุทีละคอลัมน์ (whatsnew ใช้ dtype="str" กับทั้งไฟล์) และยังไม่ได้รันกับ pandas 3.1.0 จริง:

import pandas as pd

df = pd.read_csv("customers.csv", dtype={"zip": "str"})
df["zip"] = df["zip"].astype("category")  # เลขศูนย์นำหน้ายังอยู่

2. อัป numexpr เป็น 2.14.2 ขึ้นไปพร้อมกัน
3. อัปใน venv แยกด้วย python -m pip install --upgrade pandas แล้วรันงานเดิมกับไฟล์จริง เทียบจำนวนแถว ยอดรวม และชนิดข้อมูลของคอลัมน์รหัสก่อนย้ายงานจริง (ข้อนี้เป็นคำแนะนำของผม)

รายละเอียดเต็มอยู่ในบทความ pandas 3.1.0

สิ่งที่ยังไม่ชัด และจุดที่แหล่งข้อมูลพูดไม่ตรงกัน

• LiteLLM ควรล็อกรุ่นไหน: LiteLLM, Datadog และ Wiz ยังเขียนว่า 1.106.2 ส่วน StepSecurity อัปเดตเป็น 1.106.4 หรือ backport ทั้งสองรุ่นไม่โดน ต่างกันที่ 1.106.3 ขึ้นไปเซ็นด้วย cosign key ใหม่และถอด root CA ของ eMudhra ออกแล้ว นอกจากนี้ LiteLLM บอกว่ามีช่องโหว่ของรุ่น enterprise ที่นัดเปิดเผย 27 ตุลาคม ตอนที่ตรวจยังไม่มีประกาศออกมา
• GitLab: issue ของช่องโหว่ยังปิดเป็นความลับตามรอบ 90 วัน และผมยังไม่เจอโค้ดสาธิตการเจาะที่เผยแพร่
• Python: ยังไม่มีตัวติดตั้งของสาย 3.13 ที่มีการบล็อกในโมดูล ssl
• Java: เลขรุ่นแก้ของ GraalVM และของ Temurin, Corretto, Zulu แต่ละค่าย ผมยังไม่ได้ตรวจ และชื่อ alias ของ root ต่างกันตามผู้ผลิต คำสั่ง keytool -delete ตามชื่อของ Oracle จึงอาจลบไม่โดนบน build ค่ายอื่นแบบไม่แจ้งอะไร
• pandas: ตัวเลข “เร็วขึ้น 2–3 เท่า” มาจากทีม pandas เอง ยังไม่มีผลทดสอบอิสระ

Recap: เช็กลิสต์ก่อนปิดเรื่อง

• ไม่มี litellm==1.107.0 ใน lockfile, venv, image หรือ cache และถ้าเคยมี ได้สร้างเครื่องใหม่และเปลี่ยนกุญแจทุกตัวจากเครื่องสะอาดแล้ว
• GitLab self-managed เป็น 19.5.1 / 19.4.3 / 19.3.6 (หรือรุ่น backport) และไล่ log ตามกฎตรวจจับแล้ว
• Python เป็น 3.15.2 / 3.14.10 (หรือรุ่น source ของสายเก่า) และ pip ≥ 26.2.2 ในทุก venv
• Oracle JDK เป็นรุ่น .0.3 หรือ 8u511-b33 ส่วน OpenJDK ค่ายอื่นรัน CheckCerts แล้วขึ้น “No bad root certificates found”
• Docker image ที่เกี่ยวข้อง build ใหม่โดยไม่ใช้ layer cache
• ก่อนอัป pandas 3.1.0 เช็กคอลัมน์รหัสที่อ่านเป็น category และอัป numexpr เป็น 2.14.2 ขึ้นไป

ดูเวอร์ชันเล่าเร็วได้ที่คลิปสายเดฟประจำสัปดาห์ ส่วนภัยฝั่งผู้ใช้ทั่วไปและแอดมิน (หลอกจ่ายค่าไฟ, ClickFix, Plex, UpdraftPlus, GlobalProtect) อยู่ในคู่มือเช็กและแก้ 5 ภัยไซเบอร์ครับ