Cache poisoning using NULL bytes and long URLs

ID H1:334709
Type hackerone
Reporter irvinlim
Modified 2018-09-16T14:22:51


This is related to a previous report I made ( The same endpoint ( is still vulnerable to arbitrary string injection, by terminating the customer key in the for parameter with a URL-encoded NULL byte (i.e. %00), followed by an arbitrary string of text.

Although this may seem trivial since strings are URL escaped anyway (see the previous report), I realised that we can inject an extremely large number of arbitrary characters after the NULL byte, which will be propagated to the boardURI and applicationURI values in the Grnhse.Settings object, as follows:

Grnhse.Settings = { targetDomain: '', scrollOnLoad: true, autoLoad: true, boardURI: '', applicationURI: '', baseURI: '', iFrameWidth: 650 };

This generated JS file is cached on the Greenhouse CDN/servers for an undetermined amount of time, which allows the same poisoned JS file to be loaded from the original URL at This means that when a job application page is requested using applicationURI as the prefix, the extremely long URL will be prefixed onto the actual iframe URL.

We can see that the value of the applicationURI URL prefix is 6155 bytes long, which is close to the maximum number of bytes in the URL I was able to send to the server, before receiving ERR_CONNECTION_CLOSED. Since the applicationURI usually takes the form, where the token parameter is around 6-7 bytes long, these extra bytes for the token parameter are just enough so that the URL is now around 6169 bytes, enough to cause a ERR_CONNECTION_CLOSED error from the web server when the user opens the job application page with an iframe, resulting in a denial of service preventing him/her from loading the job application URL.

As an example, try to visit the following URL, where I added &token=1234567 onto the applicationURI above:

I have omitted the proof of concept that this exploit bricks a live job board from start to finish, since it has already been proven in the previous report that we can cause a denial of service by changing the applicationURI in the JS file. If necessary, I will try to reproduce it on an actual job board, but I do not own a Greenhouse account to test it on.

However, I have attached a proof of concept for cache poisoning the JS file, which shows that the NULL bytes and the arbitrary strings are able to be injected into the applicationURI value.

Proof of Concept

Visit, whose cache is still poisoned at the moment.

Root Cause

The for parameter value is being copied verbatim into the resultant URL in the JS file.


If an attacker has knowledge about the underlying cache and network architecture, the attacker could attempt to poison the cache reliably, resulting in an extended denial of service of Greenhouse job boards/application iframes in client sites.