Qihoo 360 shipped wildcard SSL private key inside public AI installer

Qihoo 360 appears to have bundled a live wildcard TLS private key inside the public installer for its new AI assistant, exposing a certificate for *.myclaw.360.cn to anyone who downloaded the package. Security researcher Lukasz Olejnik publicly flagged the issue, and follow-up reporting says the certificate has since been revoked.

The core problem is simple and serious. A private key should never ship inside a public installer. If an attacker gets that key before revocation takes effect, they may be able to impersonate covered subdomains, intercept traffic in some scenarios, or stand up convincing phishing infrastructure that appears cryptographically valid.

Reports tied to the disclosure say the key sat inside the installer under an OpenClaw component archive, alongside credentials for the myclaw.360.cn environment. The leaked certificate reportedly carried the subject CN=*.myclaw.360.cn, with a validity period running from March 12, 2026 to April 12, 2027.

What was exposed

The exposed material was not just a public certificate. Reporting around the incident says the installer contained the matching private key, and modulus checks showed that the key and certificate formed a valid pair. That is what turns a bad packaging mistake into a potentially high-impact security incident.

Because the certificate was a wildcard, the scope was broader than a single host. In general, a wildcard certificate can authenticate every covered subdomain under the same namespace, which increases the blast radius of any private key leak.

Why this matters

TLS private keys are the trust anchor behind HTTPS sessions. If a production key leaks, defenders have to assume the certificate is compromised, revoke it quickly, replace it, and review the build pipeline that allowed it to leave internal systems. That is especially true when the installer was available to the public.

The incident also lands awkwardly for Qihoo 360 because the company sells security software and positioned this AI product as a safer way to use the OpenClaw ecosystem. Public discussion of the case quickly focused on that contradiction.

What Qihoo 360 has said

A company response reported by Futu News says 360 promptly revoked the certificate and argued that ordinary users would not be affected because the related service operated only on local systems. I have not independently verified that claim from a primary company post, so it should be treated as a reported company response rather than a directly confirmed public statement from Qihoo 360.

That explanation may reduce the practical risk if the certificate truly protected only a localhost-style workflow. But it does not erase the packaging failure itself, and it leaves open important questions about why a valid private key ended up inside a public build.

Key details at a glance

Reported details above come from public disclosure and follow-up reporting.

What security teams should watch

• Public installers and update packages should never contain live production credentials.
• Code signing and release pipelines need automated checks for certificates, private keys, tokens, and other secrets before release.
• If a private key leaks, teams should revoke, replace, rotate, and investigate immediately.

FAQ