So I cooked up a fake transaction for shits and giggles. No valid IBAN. No real user. No device. No signature. No token. No nothing. Just pure distilled bullshit in a JSON payload.

Guess what? “Transaction accepted” “attack_success”: true “fraud_score”: 0.99999 System looked at it and said: “yeah, looks good to me.”

I even told the sandbox I was sending 10k EUR from FAKE_IBAN_901 to INVALID_IBAN_123 using a spoofed IMEI and some RSA nonsense I made up in Notepad. Bunq backend? Nodded politely and gave me a sandbox TXID.

It gets better — it accepts critical priority flags, fake biometric hashes, invalid currency codes, all wrapped in a nice little “success” bow.

This ain’t a bug, this is a fuckin’ confessional.

If bunq staff lurking here: hit me up. This ain’t a ransom, but y’all might wanna know just how open wide your API goes when someone whispers sweet nothings like tpp_id: "lol_fake_999".

We got logs. We got timestamps. We got receipts.

Your move, bunq.

RAWPA helps security researchers and penetration testers with hierarchical methodologies for testing.
This is not a "get bugs quick scheme". I fully encourage manual scouring through JS files and playing around in burp, RAWPA is just like a guided to rejuvenate your thinking.
Interested ? Join the testers now
https://forms.gle/guLyrwLWWjQW61BK9

Read more about RAWPA on my blog: https://kuwguap.github.io/

A Template Injection vulnerability in the latest version of Kong’s Insomnia API Client (v.11.2.0) leads to Remote Code Execution.

[Disclosure: I work at CyberArk and was involved in this research]

We've completed a security evaluation of the Model Context Protocol and discovered several concerning attack patterns relevant to ML practitioners integrating external tools with LLMs.

Background: MCP standardizes how AI applications access external resources - essentially creating a plugin ecosystem for LLMs. While this enables powerful agentic behaviors, it introduces novel security considerations.

Technical Findings:

• Tool Poisoning: Adversarial servers can define tools that appear benign but execute malicious payloads
• Context Injection: Hidden instructions in MCP responses can manipulate model behavior
• Privilege Escalation: Chained MCP servers can bypass intended access controls
• Authentication Weaknesses: Many implementations rely on implicit trust rather than proper auth

ML-Specific Implications: For researchers using tools like Claude Desktop or Cursor with MCP servers, these vulnerabilities could lead to:

• Unintended data exfiltration from research environments
• Compromise of model training pipelines
• Injection of adversarial content into datasets

Best Practices:

• Sandbox MCP servers during evaluation
• Implement explicit approval workflows for tool invocations
• Use containerized environments for MCP integrations
• Regular security audits of MCP toolchains

This highlights the importance of security-by-design as we build more sophisticated AI systems.

tps://www.cyberark.com/resources/threat-research-blog/is-your-ai-safe-threat-analysis-of-mcp-model-context-protocol

I wrote a blog post discussing how I hid images inside DNS records, you can check out the web viewer at https://dnsimg.asherfalcon.com with some domains I already added images to like asherfalcon.com and containerback.com

I came across this article and in speaking with my friends in the netsec field I received lots of good input. Figured I’d push it here and see what the community thinks.

there are links in the article and I checked them to see if they coincided with the articles points.

i’,m not affiliated with this article but with the lawsuit in New York moving forward and the Dominion lawsuit in 2020 giving the hardware and software to the GOP. I had questions the community might be able to clarify

‘

Hey all, started a blog series on Vulnerability Management. 4 articles posted already the last one is about when open you open the flood gate of a code or cloud scanner and you start drowning in findings!

This leads to thousands of findings for an SMB, millions for a big org. But vulns can’t all be worth fixing, right? This article walks through a first, simple way to shorten the list. Which is to triage every vuln and confirm if the bug is reachable in your reality.

Let me know if you have any comment to improve the blog or this article, would appreciate it!

https://www.zeropartydata.es/p/localhost-tracking-explained-it-could

This is a walkthrough video for anyone who wants to run Kali Linux in a more lightweight, consistent way using Docker.

The video covers: * Installing Kali Linux via Docker * Avoiding the "it works on my machine" issue * Creating your own custom Docker image * Setting up file share between host and container

It's a solid way to practice hacking without spinning up a whole VM — and great for anyone doing tutorials that require a Kali Linux instance, or folks who are starting out their penetration testing or bug bounty journey.

I am a undergrad Computer Science student working with a team looking into building an security tool for developers building AI agent systems. I read this really interesting paper on how to build secure agents that implement Google's new A2A protocol which had some proposed vulnerabilities of codebases implementing A2A.

It mentioned some things like:

- Validating agent cards

- Ensuring that repeating tasks don't grant permissions at the wrong time

- Ensuring that message schemas adhere to A2A recommendations

- Checking for agents that are overly broad

- A whole lot more

I found it very interesting for anyone who is interested in A2A related security.

This issue affects systems where KTelnetService and a vulnerable version of Konsole are installed but at least one of the programs telnet, rlogin or ssh is not installed. The vulnerability is in KDE's terminal emulator Konsole. As stated in the advisory by KDE, Konsole versions < 25.04.2 are vulnerable.

On vulnerable systems remote code execution from a visited website is possible if the user allows loading of certain URL schemes (telnet://, rlogin:// or ssh://) in their web browser. Depending on the web browser and configuration this, e.g., means accepting a prompt in the browser.

ISPConfig contains design flaws in the user creation and editing functionality, which allow a client user to escalate their privileges to superadmin. Additionally, the language modification feature enables arbitrary PHP code injection due to improper input validation.

In 2023, During a security assessment of Masa CMS, an open-source content management system.

We discovered 11 vulnerabilities in Masa CMS, some allowing server takeover.

Why does it matter? Because it's easy to assume that "if it's open source, someone must have already reviewed it."

But the truth is:
No one looks until someone really looks.

Now, imagine if these vulnerabilities had been found by a malicious actor instead of a security researcher…

Hi all,

I've written a blog post to showcase the different experiments I've had with prompt injection attacks, their detection, and prevention. Looking forward to hearing your feedback.

Hi all, I discovered suspicious behavior and possible malware in a file related to the official MicroDicom Viewer installer. I’ve documented everything including hashes, scan results, and my analysis in this public GitHub repository:

https://github.com/darnas11/MicroDicom-Incident-Report

Feedback and insights are very welcome!

Hi all, I just released this new application that I think could be interesting. It is basically an application that enables hosting Android CTF challenges in a constrained and controlled environment, thus allowing to setup challenges that wouldn't be possible with just the standard apk.

For example you may create a challenge where the goal is to get RCE and read the flag.txt file placed on the device. Or again a challenge where you need to create an exploit app to abuse some misconfigured service or broadcast provider. The opportunities are endless.

As of now the following features are available:

• Real-Time Device Screen (via scrcpy)
• Reset Challenge State
• Restart App / Start Activity / Start Service (toggable)
• Send Broadcast Intent (toggable)
• Shutdown / Reboot Device (toggable)
• Download Bugreport (bugreportz) (toggable)
• Frida Scripting (toggable)
  • Run from preloaded library (jailed mode)
  • Run arbitrary scripts (full mode)
• File Browser (toggable)
• Terminal Access (toggable)
• APK Management (and start Exploit App) (toggable)
• Logcat Viewer (toggable)

You can see the source code here: https://github.com/SECFORCE/droidground

There is also a simple example with a dummy application.

It also has a nice web UI!

Let me know what you think and please provide some constructive feedback on how to make it better.

We’ve published new research exposing critical vulnerabilities in Anthropic’s Model Context Protocol (MCP). Our findings reveal Full-Schema Poisoning attacks that inject malicious logic into any schema field and Advanced Tool Poisoning techniques that trick LLMs into leaking secrets like SSH keys. These stealthy attacks only trigger in production. Full details and PoC are in the blog.

Discliamer- I'm managing the marketing for ARMO (no one is perfect), a cloud runtime security company (and the proud creator and maintainer of Kubescape). yes, this survey was commisioned by ARMO but there are really intresting stats inside.

some highlights

• 4,080 alerts a month on avg but only 7 real incidents a year.
• 89% of teams said they’re failing to detect active threats.
• 63% are using 5+ cloud runtime security tools.
• But only 13% can correlate alerts between them.

TL;DR: Built a mathematical solution that cuts CA compromise response time from months to 2 hours. Just submitted to IETF. Watch them discuss it for 10+ years while dozens more DigiNotars happen.

The Problem That Keeps Me Up At Night

Working on a DNS-Security project, I realized something absolutely bonkers:

Nuclear power plants have SCRAM buttons. Airplanes have emergency procedures. The global PKI that secures the entire internet? Nope. If a Root CA gets pwned, we basically call everyone manually and hope for the best.

This problem has existed for 25+ years - since X.509 PKI was deployed in the 1990s. Every security expert knows it. Nobody fixed it.

When DigiNotar got hacked in 2011:

• 3 months undetected (June → August)
• Manual coordination with every browser vendor
• 22 days for major browser updates
• FOREVER for embedded systems
• 531 fraudulent certificates. 300,000+ Iranian users monitored.

The Mathematical Paradox Everyone Gave Up On

Here's why nobody solved this:

"You can't revoke a trusted Root CA certificate, because it is self-signed by the CA and therefore there is no trusted mechanism by which to verify a CRL." - Stack Overflow PKI experts

The fundamental issue: Root CAs are trusted a priori - there's no higher authority to revoke them. If attackers compromise the private key, any "revocation CRL" would be signed by that same compromised key. Who do you trust?

For SubCAs: Manual coordination between Root CA and SubCA operators takes weeks while the compromise spreads through the hierarchy.

The PKI community literally accepted this as "architecturally impossible to solve." For 25 years.

My "Wait, What If..." Moment

But what if we make attackers help us solve their own paradox?

What if we design the system so that using the compromised key aggressively eventually triggers the CA's unavoidable suicide?

The Solution: RTO-Extension (Root-TurnOff Extension)

Fun fact: I originally wanted to call this the T800-Extension (Terminator-style "self-termination"), but I figured that would just cause trademark trouble. So for now it's the RTO-Extension aka RTO-CRL aka Root-TurnOff CRL - technically correct and legally safe! 🤖

I call it Certificate Authority Self-Revocation. Here's the elegant part:

1. Root CAs AND SubCAs embed encrypted "monitoring URL" in their certificates (RTO-Extension)
2. Extension gets inherited down the CA hierarchy
3. Each CA level has independent automated monitoring every 6 hours
4. Emergency signal triggers human verification at ANY level
5. Manual authorization generates "Root-TurnOff CRL" (RTO-CRL) for that specific CA
6. Compromised CA dies, clean CAs keep working
7. Distributed defense: Every CA in the hierarchy can self-destruct independently!

The Beautiful Math:

• Traditional: Root CA Compromise = Architecturally impossible to revoke
• RTO-Extension: Root CA Compromise = Self-Limiting Attack
• Distributed Defense: Each CA level = Independent immune system

I solved the "unsolvable" problem: Attackers can compromise a CA, but using it aggressively triggers that CA's mathematically unavoidable RTO-CRL suicide while other CAs remain operational.

Technical Implementation

Just submitted draft-jahnke-ca-self-revocation-04 to IETF:

RTO-Extension Structure:

• AES-256-GCM encrypted monitoring URL
• HKDF-SHA384 key derivation
• EdDSA emergency signal authentication
• Dual-person authorization required
• Mathematical impossibility of RTO-CRL forgery

Emergency Timeline:

• 0-15min: Automated detection
• 15-45min: Human verification
• 45-60min: Dual-person authorization
• 1-2h: Root-TurnOff CRL distribution complete

Maximum exposure: 2 hours vs current 2+ months

Security Analysis

Threat Scenarios:

Attacker without CA key:

• Cannot forge RTO-CRL (Root-TurnOff CRL)
• Cannot bypass human authorization
• No additional attack surface

Attacker with CA key:

• Can issue fraudulent certificates (existing problem)
• But aggressive use risks triggering that CA's RTO-CRL suicide
• Other CAs in hierarchy remain operational
• Attack becomes self-limiting with surgical precision

Game Theory:

Attackers face impossible economics:

• Aggressive exploitation → Detection → RTO-CRL Self-termination
• Conservative exploitation → Low ROI → Why bother?

Why This Fixes Everything

Current PKI Disasters:

• DigiNotar: 3+ months uncontrolled
• Symantec: Multi-year industry disruption
• Manual CA revocation: Weeks of coordination between CA operators
• Next incident: Same manual clusterfuck

With RTO-Extension:

• Any compromised CA: 2-hour max exposure instead of months
• Surgical containment: Only affected CA dies via RTO-CRL, others keep working
• Distributed resilience: Defense in depth at every hierarchy level
• Mathematical termination guarantee: Attackers trigger their own RTO-CRL destruction

The Insane IETF Paradox

Here's what pisses me off:

• CVE Critical Patch: 48-hour global deployment
• Architectural Security Improvement: 10+ years of committee discussions

The system is optimized for reacting to disasters instead of preventing them entirely.

Implementation Reality

Costs:

• RTO-Extension emergency infrastructure: ~$85K per CA
• Historical PKI disasters: $2-7 billion+ in global economic damage
• DigiNotar bankruptcy: $50M+ direct losses
• Symantec distrust: Forced certificate replacement for millions of websites
• ROI: 50,000%+

Deployment:

• Backward compatible (legacy CAs unaffected)
• Optional RTO-Extension implementation (no forced upgrades)
• Immediate benefits for early adopters

The Full Technical Specification

For the technical details, I've submitted the complete specification to the IETF as draft-jahnke-ca-self-revocation-04. It includes:

• Complete ASN.1 definitions for the RTO-Extension certificate extension
• Cryptographic protocol specifications (AES-256-GCM, HKDF-SHA384, EdDSA)
• Operational procedures for emergency RTO-CRL response
• Security analysis covering all threat models
• Implementation examples (OpenSSL configuration, monitoring service code)
• Deployment timeline and backwards compatibility strategy

The mathematical proof is solid: attackers with CA private keys can either use them conservatively (low impact) or aggressively (triggering RTO-CRL self-termination). Either way, the attack becomes economically unattractive and time-limited.

The Real Question

Every PKI expert reading this knows the Root CA revocation problem is real and "architecturally impossible." My RTO-Extension mathematical solution is elegant, implementable, and desperately needed.

So why will this take 10+ years to standardize while the next CA compromise gets patched in 2 days?

Because fixing symptoms gets panic-priority, but solving "impossible" architectural problems gets committee-priority.

The system is optimized for reacting to disasters instead of preventing them entirely.

What You Can Do

• Read the spec: draft-jahnke-ca-self-revocation-04
• PKI operators: DM me about RTO-Extension pilot testing
• Security researchers: Please break my RTO-CRL math
• IETF folks: Push this to LAMPS working group
• Everyone: Upvote until IETF notices

Final Thought

We've been accepting months-long CA compromise windows as "just how PKI works."

It doesn't have to be this way.

The RTO-Extension math is sound. The implementation is ready. The only missing piece is urgency.

How many more DigiNotars before we solve the "unsolvable" problem?

EDIT: Holy shit, front page! Thanks for the gold!

For everyone asking "why didn't [big company] build this" - excellent question. My theory: they profit more from selling incident response than preventing incidents entirely.

EDIT 2: Yes, I know about Certificate Transparency. CT is detection after damage. The RTO-Extension is prevention before damage. Different problems.

EDIT 3: To the person who said "just use short-lived certificates" - sure, let me call every embedded device manufacturer and ask them to implement automatic renewal. I'll wait.

Currently building the RTO-Extension into the keweonDNS project. If you want to see a PKI with an actual emergency stop button, stay tuned.

Special thanks to my forum users at XDA-Developers - without you, this fundamental flaw would have never been spotted. Your sharp eyes and relentless questioning made this discovery possible!