CVE-2026-100601: ClawHub SSRF via Unchecked DNS Resolution in Profile Image
ClawHub (openclaw/clawhub) application/backend contains a server-side request forgery vulnerability in the public profile preview's image fetching. The preview accepts a user-supplied image URL and checks the textual hostname against private-address patterns, but does not validate or pin the resolved network destination, so a public-looking hostname can resolve to an internal address or change resolution between validation and connection (DNS rebinding). A maintainer-run local harness demonstrated an outbound connection to an owner-controlled loopback listener; access to production internal services, credential disclosure, and code execution were not demonstrated. The issue was confirmed at revision cbfee7343ddc867316dd9b3de6fa8856730f9f41; the complete historical affected range was not established. Fixed by PR #3683, included in revision 8c2de6c506bb4efabe3f0c2ffb8370b9e23d4650, which was deployed to clawhub.ai on 2026-09-11; self-hosted deployments should update to that revision or a later descendant. The npm CLI and OpenClaw runtime are separate products and are not affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
openclaw/clawhubto a version that resolves this vulnerability.Patch PR #3683, included in revision 8c2de6c506bb4efabe3f0c2ffb8370b9e23d4650
Event History
Frequently Asked Questions
Which deployments are affected?
The issue affects the ClawHub application/backend's public profile preview image-fetching path. The npm CLI and OpenClaw runtime are separate products and are not affected.
What does an attacker need to exploit this?
An attacker needs to provide a profile image URL using a public-looking hostname that resolves to an internal address, or whose DNS resolution changes after hostname validation. No privileges or user interaction are required according to the supplied vector.
Are hosted ClawHub users still exposed?
The fix was deployed to clawhub.ai on 2026-09-11. Self-hosted instances should verify that they run revision 8c2de6c506bb4efabe3f0c2ffb8370b9e23d4650 or a later descendant.
What should self-hosted operators do if they cannot update immediately?
The provided data establishes that the vulnerable behavior is in public profile preview image fetching and relies on attacker-controlled image URLs and DNS resolution. It does not provide a validated temporary mitigation; updating to the fixed revision or later is the documented remediation.
How can an operator determine whether their instance may be affected?
Revision cbfee7343ddc867316dd9b3de6fa8856730f9f41 was confirmed vulnerable, while revision 8c2de6c506bb4efabe3f0c2ffb8370b9e23d4650 includes the fix. The complete historical affected range was not established, so versions between or outside those revisions cannot be classified from the available data alone.