ClawHub security reporting

Security reporting fails more often on routing than on effort. A report filed in the wrong place reaches someone who cannot fix the bug, and the fix waits. ClawHub draws one clear line through this, sending problems in the registry itself to its own security advisories and problems in a third-party skill or plugin to whoever wrote them. Working out which side of that line you are on takes a moment and saves days.

What belongs in an advisory

• ClawHub security issues can be reported through GitHub Security Advisories for the ClawHub repository, and a good report covers the ClawHub website, API or CLI, registry publishing, downloads, installs or artifact integrity, authentication, authorisation or API tokens, or scanning, moderation and report handling.
• Vulnerabilities in a third-party skill or plugin's own source code do not belong in ClawHub advisories and should be reported directly to the publisher or to the source repository linked from the ClawHub listing.
• Because ClawHub is a hosted cloud application, its service vulnerabilities are not publicly disclosed by default, and they are disclosed when there is evidence of real user impact or when users need to take action.
• Vulnerabilities in user-installed software are publicly disclosed, including ClawHub CLI packages, binaries, libraries and other release artifacts that users need to update locally.

Because ClawHub is a hosted cloud application, ClawHub service vulnerabilities are not publicly disclosed by default.

When disclosure happens

The disclosure rule is easier to follow once you see what it turns on. A hosted service can be repaired centrally, so a fixed service bug leaves nothing for a user to do and the default is no public disclosure. Disclosure is triggered instead by evidence of real user impact or by a need for users to take action. The examples given for real user impact are concrete, namely confirmed exploitation, exposure of user data or secrets, malicious content reaching users because of a platform failure, and any issue that requires users to rotate credentials, update local software or take other protective action. Each of those is something a user has to respond to, which is exactly why it changes the answer. Software installed by users is the mirror image, since nobody can update it on their behalf. That is why vulnerabilities in user-installed software are publicly disclosed, including CLI packages, binaries, libraries and other release artifacts. Read the rule as a test of whether you need to do something, not as a measure of how serious the bug was.

Where other answers live

• Install-time audit labels, risk levels, findings and how to interpret them are covered on the ClawHub security audits page rather than through the advisory process.
• Marketplace reports, moderation holds, hidden listings, bans and account standing are covered on the moderation and account safety page.
• A listing links back to the publisher and the source repository, and that is the route to use for a bug in the package's own code rather than in the registry.

The ClawHub side of security stops at the registry, covering the website, the API and the CLI, registry publishing, downloads, installs and artifact integrity, authentication, authorisation and API tokens, and scanning, moderation and report handling. Everything that happens after a package reaches your own machine is a separate subject, covered in Agent sandboxing and Tool approvals.

Why the policy splits this way

The split is a routing decision rather than a disclaimer. ClawHub can fix its own website, API, CLI, publishing path, downloads, installs, tokens and moderation tooling, so those reports belong with ClawHub and arrive through its security advisories. It cannot fix code inside a third-party skill or plugin, so those reports belong with the publisher or the source repository linked from the listing, where the person who can actually patch the code will see them. The disclosure default follows the same logic, because a hosted cloud application is repaired once for everyone, while an artifact already installed locally stays broken until its owner updates it. Publication is therefore reserved for evidence of real user impact or for cases where users have to act, such as rotating credentials or updating local software. That keeps the public record useful, since every disclosed item is one a reader may need to do something about. The publishing side of the same question continues in Publishing scopes and owners and Release provenance.

On Diali

Diali hosts OpenClaw, and each customer runs their own assistant with state on a persistent volume; daily snapshots and one-click restore are available through the Backups add-on (included on Max). The runtime configuration is generated from the dashboard and replaced at each release, and channels are connected from that same dashboard. See Hosted OpenClaw on Diali for the hosted runtime and Diali security for how we handle our side.

• Registry bugs go to ClawHub advisories, package bugs to the publisher.
• A hosted fix needing no user action is not disclosed by default.
• Anything you must update locally is disclosed publicly.