Summary · Attack Flow · Affected Code · Proof · Remediation · Timeline · References

📋 At a glance

🔎 Summary

Emlog Pro ships an admin-facing AI assistant (admin/ai.php + include/service/ai.php) that makes outbound HTTPS calls to a configured LLM provider — chat, streaming, image generation — plus a Bing-scraping helper for the @em-help command.

Every outbound request helper unconditionally disables TLS certificate validation:

Verification is off regardless of the configured provider URL or network path, so any network-adjacent / man-in-the-middle attacker sitting between the Emlog server and the api_url can transparently intercept the TLS session with a forged certificate and:

• 🔑 Steal the Authorization: Bearer <apiKey> header — the site's paid LLM-provider API key.
• 💉 Inject a malicious AI response back into the assistant, which drives an LLM that holds query_database and update_config tool access.

This is a pure transport-security defect — it is not gated behind the AI tool-calling confirmation UI.

🧭 Attack Flow

💥 Impact

• API-key disclosure — theft and financial abuse of the site's paid LLM-provider key.
• Response injection — attacker-controlled content enters the AI assistant's stream.
• Low bar to exploit — any network-adjacent position (shared hosting, hostile Wi-Fi, compromised router, malicious egress proxy) is enough; no credentials on the Emlog install are required.

📂 Affected Code

include/service/ai.php — the CURLOPT_SSL_VERIFYPEER / CURLOPT_SSL_VERIFYHOST calls in:

🧪 Proof / Verification

🛠️ Remediation

Enable TLS verification for all outbound calls in include/service/ai.php:

Self-hosted / OpenAI-compatible endpoints with a private CA should be supported via a custom CA bundle (CURLOPT_CAINFO) — never by disabling verification globally.

🔗 Related note (same feature, separate hardening)

While auditing the same AI feature, Ai::queryDatabase() was found to specially block direct SQL writes to the blog table but not the user table (which holds role / password). Combined with the indirect-prompt-injection path via @em-help (live Bing results + scraped FAQ fed into a model that has query_database / update_config tool access), this is worth hardening by routing user / options writes through narrowly-scoped tools — the way write_article already handles blog posts. Full details in REPORT.md (tracked separately from the CVE above).

🗓️ Timeline

📚 References

• 🆔 CVE Record — https://www.cve.org/CVERecord?id=CVE-2026-67598
• 🛡️ NVD — https://nvd.nist.gov/vuln/detail/CVE-2026-67598
• 📢 GitHub Advisory — GHSA-hf85-99vj-m4c5
• 📦 Vendor — https://github.com/emlog/emlog
• 📝 Full write-up — REPORT.md

_{Published for educational and defensive-security purposes as part of coordinated disclosure.
Discovered & reported by Ilhomjon Rustamov (@IlhomjonR) · CNA: VulnCheck}