Bug Hermes Update Bisa Menurunkan Dependency yang Sudah Dipatch: Audit dan Mitigasi

Perintah hermes update pada Hermes Agent 0.19.0 dapat menurunkan versi dependency yang sebelumnya sudah diperbarui. Efeknya bukan sekadar package churn: environment yang sudah memakai versi perbaikan keamanan bisa kembali ke pin lama. Patch sudah masuk branch utama pada 27 Juli 2026, tetapi belum tersedia dalam release stabil baru.

Apa masalahnya

Hermes memakai exact pin untuk beberapa dependency sensitif. Pin seperti ini membantu menjaga environment konsisten, tetapi juga memaksa pip memasang versi yang tercantum saat proses update.

Pada issue #60685, operator melaporkan tiga downgrade setelah menjalankan hermes update:

• cryptography dari 48.0.1 ke 46.0.7;
• starlette dari 1.3.1 ke 1.0.1;
• python-multipart dari 0.0.31 ke 0.0.27.

Versi yang lebih baru sebelumnya dipasang manual atau ikut ter-resolve lewat dependency lain. Karena metadata Hermes masih memakai exact pin lama, update inti mengembalikannya ke versi tersebut.

Masalah ini penting karena pin itu berada di area dependency yang terkait perbaikan CVE. Update aplikasi seharusnya tidak menurunkan environment yang sudah lebih aman.

Dampak operasional

Bug ini tidak otomatis berarti setiap instalasi Hermes sudah dieksploitasi. Ini juga bukan bukti remote compromise. Dampak langsungnya adalah security posture yang mundur diam-diam setelah update.

Operator paling berisiko adalah yang:

• menjalankan Hermes Agent 0.18.x atau 0.19.0;
• memakai fitur web, dashboard, MCP, computer-use, WeCom, atau Weixin;
• pernah memperbarui dependency secara manual;
• menganggap hermes update selalu mempertahankan versi patch yang lebih baru;
• tidak melakukan dependency audit setelah update.

Downgrade juga dapat memicu konflik. Commit perbaikannya mencatat cryptography lama tidak cocok dengan kebutuhan hindsight-api-slim, sementara versi 49.x belum bisa dipakai karena msal dan alibabacloud-tea-openapi masih membatasi versi di bawah 49.

Apa yang sudah diperbaiki upstream

Commit 623762f2 memperbarui pin menjadi:

• cryptography==48.0.1;
• starlette==1.3.1;
• python-multipart==0.0.32.

Lockfile juga diregenerasi. Untuk dependency Alibaba Cloud, alibabacloud-tea-openapi naik ke 0.4.5 agar batas kompatibilitas cryptography <49 tetap terpenuhi.

Upstream menambahkan regression guard di test packaging. Tujuannya jelas: pin yang sudah ditetapkan sebagai lantai keamanan tidak boleh mundur lagi pada perubahan berikutnya.

Patch tersebut menutup issue #60685 di branch utama. Namun saat audit ini dilakukan pada 27 Juli 2026, release stabil terbaru masih v2026.7.20 / Hermes Agent 0.19.0. Jadi pengguna release stabil belum otomatis menerima fix hanya dengan melihat bahwa commit sudah merged.

Cara audit instalasi sekarang

Cek versi package dari virtual environment Hermes, bukan Python global:

~/.hermes/hermes-agent/venv/bin/python -m pip show \
 cryptography starlette python-multipart

Untuk instalasi yang memakai layout berbeda, cari interpreter yang benar dari service atau launcher Hermes lalu jalankan python -m pip show dari environment tersebut.

Versi yang perlu diperhatikan:

• cryptography di bawah 48.0.1;
• starlette di bawah 1.3.1;
• python-multipart di bawah 0.0.32 jika extra web atau dashboard dipakai.

Jangan menilai hanya dari pip global. Service bisa tetap berjalan dari virtual environment lama meskipun shell utama menampilkan package yang sudah baru.

Mitigasi sebelum patch release tersedia

1. Catat versi sebelum dan sesudah update

Ambil snapshot dependency sebelum menjalankan hermes update, lalu bandingkan setelahnya:

~/.hermes/hermes-agent/venv/bin/python -m pip freeze > hermes-before.txt
hermes update
~/.hermes/hermes-agent/venv/bin/python -m pip freeze > hermes-after.txt
diff -u hermes-before.txt hermes-after.txt

Review khusus package keamanan dan dependency yang dipakai plugin aktif.

2. Pulihkan pin yang aman bila ter-downgrade

Jika audit menemukan versi lama, pulihkan versi yang sudah dipilih upstream:

~/.hermes/hermes-agent/venv/bin/python -m pip install --upgrade \
 'cryptography==48.0.1' \
 'starlette==1.3.1' \
 'python-multipart==0.0.32'

Setelah itu restart service Hermes dan jalankan smoke test pada gateway, dashboard, provider, serta memory backend yang benar-benar dipakai.

3. Jangan memakai 49.x secara paksa

Memasang cryptography paling baru tanpa mengecek resolver bukan keputusan yang aman. Upstream sengaja memilih 48.0.1 karena beberapa dependency masih memberi batas <49. Ikuti kombinasi yang sudah diuji di branch utama atau verifikasi seluruh dependency graph sendiri.

4. Pantau release resmi berikutnya

Commit di branch utama belum sama dengan patch release. Tunggu changelog yang secara eksplisit membawa perbaikan pin ini, lalu upgrade secara terukur. Setelah upgrade, ulangi pemeriksaan versi untuk memastikan environment nyata sesuai lockfile.

Apakah perlu menghentikan Hermes Agent?

Tidak ada dasar untuk menghentikan semua instance hanya karena bug ini. Keputusan yang lebih proporsional adalah audit dependency, pulihkan versi yang turun, dan batasi exposure fitur web sampai verifikasi selesai.

Jika instance menghadap internet dan memakai dashboard atau endpoint web, jadikan pemeriksaan ini prioritas. Untuk instance lokal yang tidak mengaktifkan komponen terdampak, urgensinya lebih rendah, tetapi downgrade tetap harus dibenahi agar update berikutnya tidak berjalan di atas dependency yang salah.

Kesimpulan operasional

Hermes Agent sudah memperbaiki akar masalah di branch utama, tetapi pengguna release stabil masih berada di celah waktu sebelum patch berikutnya. Jangan menganggap update selalu membuat seluruh dependency lebih baru.

Audit virtual environment setelah setiap hermes update. Targetkan minimal cryptography 48.0.1, starlette 1.3.1, dan python-multipart 0.0.32 sesuai commit upstream. Setelah patch release keluar, upgrade lalu verifikasi ulang versi aktual yang dipakai service.