Critical Shynet Flaw Let Attackers Turn Web Analytics Scripts Into a Sitewide Keylogger

A pair of security flaws in Shynet, the self-hosted web analytics platform used by developers and privacy-conscious website owners, shows how even lightweight tracking software can become a powerful attack surface when it sits inside the browser flow of multiple sites.

Security researchers at Bishop Fox disclosed two vulnerabilities in Shynet version 0.13.1 that could allow unauthenticated attackers to compromise tracked websites or hijack user accounts. The most serious issue, tracked as CVE-2026-35508, is a critical stored cross-site scripting vulnerability affecting how Shynet handled analytics request fields. A second flaw, CVE-2026-35507, is a high-severity password reset poisoning bug tied to insecure Host header validation.

The risk is unusually broad because Shynet does not just run as an admin dashboard. Like Google Analytics, Plausible, Matomo, and other analytics tools, it injects tracking scripts into websites. That means a compromise of the analytics layer can ripple outward into every web application configured to use the affected Shynet instance.

According to Bishop Fox, the stored XSS issue existed because Shynet accepted unauthenticated analytics requests and stored certain user-controlled values, including location and referrer data, before rendering them in administrative views without proper escaping. In a proof-of-concept attack, researchers showed that malicious JavaScript could be planted through the tracking endpoint and later executed when an administrator viewed the dashboard.

From there, the attack became more dangerous. The researchers demonstrated that a stored payload could modify Shynet tracking scripts across services and inject JavaScript into pages monitored by that Shynet instance. In a simulated checkout environment, the malicious script acted like a keylogger, capturing form inputs such as names, addresses, phone numbers, payment details, and other sensitive fields.

That scenario makes the flaw more than a typical dashboard XSS bug. The analytics tool becomes a supply-chain style browser compromise, where the trusted script that site owners deliberately installed can be turned against their own visitors.

The second vulnerability focused on Shynet’s password reset process. Bishop Fox found that Shynet’s configuration allowed spoofed Host header values to be used when generating password reset URLs. In deployments configured to send email through SMTP, an attacker could trigger a password reset email containing a valid reset token wrapped inside a link pointing to an attacker-controlled domain.

If the victim clicked the link, or if an email security scanner or link preview system automatically loaded it, the attacker could capture the reset token. The researchers showed that the token could then be replayed against the legitimate Shynet instance to set a new password and access the account.

The issue was tied in part to Shynet’s use of a permissive Django ALLOWED_HOSTS setting, which prevented proper validation of incoming Host header values. While default deployments using Django’s console email backend would not actually send password reset emails to users, production deployments configured with SMTP could be exploitable.

The Shynet project released version 0.14.0 on March 15, 2026, the same day Bishop Fox contacted the vendor and the vendor acknowledged the issues. The vulnerabilities were publicly disclosed on June 18, 2026.

Organizations and individuals running Shynet should upgrade to version 0.14.0 immediately, review whether any Shynet tracking scripts were modified, rotate administrator credentials, and inspect web applications monitored by affected instances for unexpected injected JavaScript. Teams using self-hosted analytics should also validate Host header handling, lock down allowed domains, and treat analytics scripts as high-trust code with access to sensitive browser-side activity.

The Shynet case is another reminder that privacy-friendly and self-hosted tools still need the same security scrutiny as commercial SaaS platforms. Analytics scripts live close to user behavior, form data, and session context. When they are compromised, the impact is not limited to the dashboard. It can reach every site that trusted the script in the first place.