“We still have not seen a single valid security report done with AI help,” was the unequivocal conclusion to a 

 by Daniel Stenberg, original author and lead of 

. 🤖 A clearly exasperated Stenberg said he would “now ban every reporter INSTANTLY who submits reports we deem AI slop”. 

, Stenberg said AI-generated reports were invariably “friendly phrased, perfect English, polite, with nice bullet-points” – and useless from a security point of view. Similarly, a software engineer at Open Collective, which manages its own program, recently complained that “

”, suggesting the inundation might ultimately force them to migrate to a Bug Bounty platform that can 

The second story on our monthly roundup (first published as a LinkedIn newsletter) involves a big win for human bug hunters (go, humanity!). A pair of researchers from Codean Labs discovered a significant 

vulnerability in OpenPGP.js that could have allowed attackers to spoof signature verification

😮 The flaw, which was reported to the 

 on YesWeHack, recently hit the headlines – attesting to the rarity, technical sophistication and impact of such cryptographic bypasses. It also reflected the wide deployment of OpenPGP.js and the potential impact on popular downstream applications. We invited researchers Edoardo Geraci and Thomas Rinsma from Codean Labs, plus OpenPGP.js maintainer Daniel Huigens, to

 comment on the discovery and disclosure process

. 💬 For an in-depth analysis of the discovery process and proof-of-concept, also read Thomas Rinsma’s 

 that documents his and Edoardo Geraci’s discovery.

Speaking of prioritising vulnerabilities, “defending against 

 continues to be a race of strategy and prioritisation,” according to an 

analysis of zero days exploited in the wild

 by the Google Threat Intelligence Group. The quartet of Google researchers who penned the blog post said zero-day vulnerabilities are “becoming easier to procure” and that “attackers finding use in new types of technology may strain less experienced vendors”.🚨The writers warn of a shift beyond a “historic focus on the exploitation of popular end-user technologies […] toward increased targeting of enterprise-focused products [which] will require a wider and more diverse set of vendors to increase 

 in order to reduce future zero-day exploitation attempts.”🛡️

Before we round up our own recent CISO-focused content, here’s a few other notable stories of interest we’ve spotted elsewhere:

CISOs bet big on AI tools to reduce mounting cost pressures

 examination of Wipro’s State of Cybersecurity Report 2025

How to survive as a CISO aka ‘chief scapegoat officer’

 reviews a recent RSA Conference panel on CISO whistleblowing

Will AI agent-fueled attacks force CISOs to fast-track passwordless projects?

‘Secure email’: A losing battle CISOs must give up

 opinion piece by Keith Lawson, CISO at the London Health Sciences Centre

How do you decide which vulnerabilities to fix first?

 Should CVSS scores be the overriding metric? 🤔 Instalment #2 in our series on continuous threat exposure management (CTEM) – which Gartner believes could lead to a two-thirds reduction in breaches – focuses on the model’s 

🧐 Learn how automated priority scores can facilitate risk-based remediation, and the benefits of consolidating multiple sources for vulnerability discovery into a single, unified interface.💡

Developers typically spent nearly two hours extra per week on security tasks in 2024 compared to the previous year, according to an IDC report.🧑💻They were even spending an average of more than three hours a week addressing unexpected security issues outside of normal working hours ⏰Suggestive of a reactive rather than proactive security culture, this context suggests two solutions to the 

: streamlining remediation and upskilling devs to prevent vulnerabilities from appearing in the first place without disrupting their workflows.✅ 

, taking place at Clermont-Ferrand in France, between 17-18 June. You can find our team and bag some swag on booth 125. Hope to see you there!

After that comes one of our most important events of the year. Taking place in Paris between 27-29 June, 

 sees us, as usual, host a live Bug Bounty event with a mystery target unveiled on-site. The marathon live hacking event will run from 10am on 28 June in ‘Le Loft’ and run until the early hours of the following morning. You can also find our team on booth 41 to talk Bug Bounty and vulnerability management. Finally, prizes will be up for grabs in relation to the successful completion of a CTF challenge crafted by our Tech Ambassador, BitK. 🏆

More conferences and live hacking events will be announced soon! 📅

Read this monthly roundup even sooner by subscribing to 

 – our LinkedIn newsletter curating news, insights and inspiration around offensive security topics like Bug Bounty, vulnerability disclosure and management, pentest management and attack surface protection.

Are you a bug hunter or do you have an interest in ethical hacking? Check out our ethical hacking-focused sister newsletter, 

 – offering hunting advice, interviews with hunters and CTF-style challenges, among other things.

‘AI slop’ bug reports and outsourcing triage, OpenPGP.js signature-spoofing bug, race to combat zero-day exploits – OffSec roundup for CISOs

Mining web archives and analysing logs is a powerful reconnaissance technique every Bug Bounty hunter should master.

Ever missed a six-figure bounty because a forgotten debug endpoint slipped through the cracks? Archive-based recon reveals the hidden treasures developers thought were buried forever. This passive approach generates zero ‘noise’ on the target’s systems, so you can scout vulnerabilities entirely undetected.

In this article, you’ll learn more about the value of archive-based recon, how to wield logs and snapshots, and a few handy commands and tools for uncovering intel that might reveal hidden security flaws.

Popular web archive recon tools
- Wayback Machine and waymore
- GetAllURLs (Gau)

Deep-dive web archive recon techniques
- Parsing archived JavaScript with LinkFinder
- Analysing logs for forgotten endpoints with TruffleHog

Putting it all together: A concise recon workflow

Expanding your toolkit: more passive recon techniques

Best practices for mitigating web archive recon

Web archive reconnaissance involves capturing and analysing historical snapshots and crawled data of a website to unearth information that is no longer visible on the live domain. Ethical hackers can then potentially leverage this info to find and exploit vulnerabilities that still exist on live systems.

This historical data can be gathered from public archives, such as Wayback Machine, CommonCrawl, Archive.today and URLScan, passively – so your traffic stays away from live servers.

So passive recon reliably evades detection and invariably steers ethical hackers away from legal risks and grey areas.

The uninitiated might surmise that a technique that eschews live, up-to-date systems in favour of months’ or years’ old data would have dubious utility.

Each archived screen capture freezes a moment in development time, preserving the so-called “nightmare leftovers”: debug panels, test APIs and credentials that developers forgot to remove.

These remnants often point directly to serious vulnerabilities, so their discovery cuts your reconnaissance time and puts you on a path to potentially high-severity and critical findings.

Web archive recon can reveal invaluable intel about:

 URLs or APIs disabled in production but still accessible, offering hidden attack surfaces

 Hardcoded tokens, credentials or configuration values in old JavaScript or config files

 Admin panels, debug consoles or staging pages that still linger in archives despite having been removed by developers

 Changelogs, README files and developer notes revealing logic or business workflows

The following are the most popular web archive recon tools – and for good reason. They are user-friendly and effective at yielding actionable insights about your targets.

These tools automate large-scale retrieval of historical data, eliminating manual effort and enabling systematic analysis.

 is an archive of snapshots that reveal how websites, and their attack surfaces, have evolved over time.

 collects archived URLs and downloads historical responses from Wayback Machine, 

Some useful information about the capabilities of various API keys, which can be stored in 

 Fetches full HTTP headers, screenshots and inline scripts

 Tags URLs with malware or suspicious content verdicts

 Uncovers shadowed references or removed assets missed by standard archives

Example 1: List all archived URLs (mode U)

This command harvests every archived endpoint in order to build your attack surface list:

Example 2: Download pages and extract JS (mode R)

This command retrieves all JavaScript responses for deep offline analysis:

Example 3: Collect archived URLs within a specific time frame (mode U + date filters)

The following command fetches only archived URLs captured between 1 January 2022 and 1 January 2023. Focusing on a specific development window, such commands can make otherwise lengthy results more manageable:

 aggregates URL lists from multiple archives in seconds, eliminating manual merging. Pulling from Wayback Machine, CommonCrawl, 

 and URLScan, it offers broad coverage. Users can filter results by extension, status code and subdomain. API keys can be stored in 

This command focuses on dynamic pages and scripts where secrets and logic hide: 

 files can expose hidden endpoints or tokens.

Now you know the basics, here are some methods for digging deeper:

Parsing archived JavaScript with LinkFinder

 extracts endpoints from offline JS files. For instance:

LinkFinder is useful because endpoints often reveal hidden API routes.LinkFinder is useful because endpoints often reveal hidden API routes.

Analysing logs for forgotten endpoints with TruffleHog

Archived logs often conceal hidden API routes, panels or tokens. 

 can scan those files and spit out any URLs or high-entropy strings directly to your console.

 to collect every path – including HTML, scripts, APIs and images.

 Test endpoints on the live site to see if they still expose data.

 to verify which assets are still active.

 CLI to reveal new subdomains without touching the target

 for historical DNS records to map past infrastructure

 to gather past registrant information and related domains

 Remove sensitive files, debug consoles and test APIs before deployment – thereby preventing archives from immortalising secrets

 and strict robots.txt rules to deter most crawlers

 Enforce authentication on log storage, rotate keys and sanitise entries to strip IPs, tokens or stack traces – thus minimising leakage

Mastering web archive and log-based reconnaissance gives you a unique window into a target’s forgotten past – unearthing endpoints, secrets and interfaces that live on in historical records.

Combine tools like waymore, gau and trufflehog with techniques such as LinkFinder parsing and methodical offline analysis and you can turn snapshots with nostalgic appeal into fuel for actionable attack paths. Following a structured workflow – harvesting every URL, analysing content offline, extracting hidden parameters and validating findings on live sites – can ensure you leave no stone unturned without running the risks entailed by implementing active recon techniques.

As for security teams, always remember to purge artefacts, steer crawlers away from sensitive sections and lock down your logs.

Whether you’re chasing your next bug or fortifying your own applications, archive-based recon is an indispensable recon method. Sometimes the past really does hold the key to your next high-impact finding in the present.

Recon Series #6: Excavating hidden artifacts with Wayback Machine and other web-archive tools

Headlines generated by a critical signature-spoofing flaw reported to the 

 attest to the rarity, technical sophistication and impact of such cryptographic bypasses.

 likely also covered the story because of the wide deployment of OpenPGP.js and the potential impact on popular downstream applications.

OpenPGP.js is an open source JavaScript implementation of the OpenPGP standard for message encryption and signing. OpenPGP is typically used for end-to-end encrypted email, signing of git commits and software releases, and encrypted file storage, among other things.

Now addressed, the OpenPGP.js vulnerability (CVE-2025-47934) could have enabled attackers to spoof signature verification and therefore dupe victims into trusting malicious messages or software commits. Credit for the discovery goes to Edoardo Geraci and Thomas Rinsma from Codean Labs, who have together netted a €7,500 bounty.

The discovery demonstrates how patience and thoroughness are the highest of virtues when it comes to finding vulnerabilities.

“We could only find this issue by taking the time to properly understand both the software's architecture and the relevant data formats,” Thomas Rinsma told YesWeHack. “It shows that when you search thoroughly, even in such a widely-used (and, presumably, widely reviewed) open source component, critical bugs may be found.”

Bug Bounty Programs allow security researchers to invest as much time as they need in performing reconnaissance and probing targets – whether their efforts take hours, weeks or even months to reach fruition. The fact that Bug Bounty rewards scale up with severity helps to incentivise and reward hunters for the time they invest (albeit high or critical severity issues aren’t necessarily 

 more time-consuming to find than lower severity flaws).

Interestingly, the Codean Labs researchers experimented on this occasion with a time-boxed approach. This “helped us stay focused on the most impactful threats,” said Thomas. “There is an optimal balance somewhere between having enough time to dig deep enough, but also having someone tell you to move on after a while.”

The vulnerability in question was uncovered when the researchers managed to validate a signature that hadn’t actually been signed by passing a maliciously modified message to either the openpgp.verify or openpgp.decrypt functions.

“In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js,” reads the relevant 

“In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature.”

Discussing the discovery process, Rinsma said: “We followed our standard asset-based methodology, where we take into account the relevant assets and attack surfaces, and analysed the flows between them. This led us to the signature verification logic where we found this flaw. Besides relying on code review, we wrote some one-off scripts to generate PGP payloads to test various edge cases in flows like this.”

For an in-depth analysis of the discovery process and proof-of-concept, read Thomas Rinsma’s 

The OpenPGP.js team released a fix and advisory just 13 days after receiving the initial vulnerability report (on 6 May), once YesWeHack’s triage team and they themselves had swiftly evaluated the issue.

“The disclosure process through YesWeHack has gone very smoothly,” said Rinsma. “The OpenPGP.js team have been nice to work with. They understood the impact and quickly coordinated with their users.”

In particular, Rinsma singled out Daniel Huigens, a maintainer of OpenPGP.js who oversaw validation and remediation, for praise.

Daniel, who also co-authored the latest version of the OpenPGP standard, told YesWeHack: “I would like to thank Edoardo Geraci and Thomas Rinsma for finding and responsibly disclosing this vulnerability, YesWeHack for hosting the Bug Bounty Program and triaging the report, and (last but not least) the Sovereign Tech Agency for sponsoring the Bug Bounty Program.”

A patch is available for users of affected versions (5.0.1 to 5.11.2 and 6.0.0-alpha.0 to 6.1.0). Should users be unable to upgrade to the patched versions, then they can alternatively follow mitigation advice contained within the advisory.

Again, for more details about this vulnerability, including mitigation advice, please check out Thomas Rinsma’s 

Open source Bug Bounty opportunities from the Sovereign Tech Resilience Program

Offering up to €10,000 for critical issues and €5,000 for high severity bugs, the bounty grid for the 

 is highly competitive. In scope at present are three assets: the high-level API of OpenPGP.js, interoperability issues in OpenPGP.js and the OpenPGP standard.

The program is one of six public Bug Bounty initiatives currently overseen by the 

, an initiative of the Sovereign Tech Agency. The other programs, which all also offer maximum rewards of €10,000, include 

, which is funded by the German government, invests in open digital infrastructure to ensure a resilient and sustainable open source ecosystem. To this end, the Sovereign Tech Agency invests in critical yet underfunded open source projects via the 

, under which otherwise volunteer maintainers of critical free and open source software (FOSS) are remunerated for their contributions.

Want to learn more about the YesWeHack Bug Bounty & Vulnerability Management platform? 

 to schedule a demo with one of our experts.

Critical signature-spoofing vulnerability in OpenPGP.js hits the headlines

, challenged the participants to bypass regex filter and exploit a command injection in Ruby's 

Want to create your own monthly Dojo challenge? Send us a message on X!

 feeds to be notified of upcoming challenges.

Read on to find out how one of the winners managed to solve the challenge.

We would like to thank everyone who participated and reported their solution for this challenge to the Dojo program. There were many great reports for this challenge and you can find the best write-up below:

The Ruby Treasure application is a web-based e-commerce platform built using Ruby. A critical vulnerability has been identified in the web application that allows an attacker to execute arbitrary system commands on the server. The vulnerability exists because the application improperly validates filenames using a regex that checks input line by line, allows special characters like pipe (

) which can be used for command execution, fails to sanitize user input before using it in file operations, and uses the ERB templating system in an unsafe manner.

The exploitation of this vulnerability allows attackers to read any accessible file on the system, including sensitive configuration files and user data. Most critically, it allows complete command execution on the underlying server, potentially leading to full system compromise.

The discovery of this vulnerability required a thorough code analysis during the initial reconnaissance phase. This involved examining the underlying Ruby technology stack, understanding how the application processes user input, and identifying potentially unsafe utility methods. By analyzing the application's validation mechanisms, file handling operations, and template rendering process, it became clear that a combination of Ruby's regex behavior with multiline strings and its special handling of pipe characters in IO operations could be leveraged to bypass security controls. This reconnaissance phase was crucial for developing a successful exploitation strategy that could overcome the input validation while achieving command execution.

The vulnerability begins at the application entry point where user input is processed. The application is designed to serve ERB templates based on user input:

The application first changes its working directory to "/tmp/app/views", which sets the context for all subsequent file operations. This is important because it establishes the base directory from which any path traversal would need to escape to access sensitive files like the flag stored at "

Next, the application defines a validation function intended to restrict the filenames that can be accessed:

This validation function contains a critical flaw. While it appears to limit filenames to alphanumeric characters, underscores, and hyphens (as per the regex pattern 

 anchors differently when processing multiline strings. In Ruby, when a string contains newlines, the regex engine evaluates the pattern against each line separately. The 

 anchor matches the beginning of any line and the 

 anchor matches the end of any line, not just the beginning and end of the entire string.

 method in Ruby will return a match if any line in a multiline string matches the pattern. This means that if any single line of a multiline input satisfies the regex pattern, the entire input will pass validation, even if other lines contain malicious characters.

The application then processes the user input:

Here, the application takes user input (which comes from the input field on the challenge page), URL-decodes it using 

 function, and then attempts to read a file with that name plus the ".erb" extension. If this file reading operation fails, it falls back to reading "

Finally, the application renders the template:

This is where the command execution vulnerability comes into play. The application reads the template file "index.erb", creates an ERB object, and passes the content read earlier as a parameter named "page". The ERB template engine evaluates any Ruby code embedded within 

The vulnerability can be exploited through a two-stage attack. First, the attacker creates a multiline input where one line (in this case, the second line) satisfies the regex validation requirement. This allows the entire multiline input to pass validation despite containing malicious characters in other lines. Second, the attacker includes command injection in the first line utilizing Ruby's IO special character handling.

The specific vulnerability exists because of several factors working together. Unlike JavaScript, Ruby's regex implementation treats 

 anchors as matching the beginning and end of any line in a multiline string, not just the entire string. This means that the validation function only needs one line in a multiline input to match the pattern for the entire input to be considered valid. Additionally, Ruby's IO operations interpret the pipe character (

) at the beginning of a filename as a command to execute, reading the output of that command instead of reading from a file. This creates a perfect storm where an attacker can craft an input that both passes validation and executes arbitrary commands.

The weird regex validation in Ruby was confirmed from the following site, where even when an invalid input is given on first line, the input on second line would give a match.

This was also confirmed from the ruby compiler:

So a payload needed to be crafted for executing the commands on the application and also to bypass the regex validation. On using the pipe (

) on the first line, we were able to get command execution when we had a payload that would pass the regex validation on the second line. On using 

 on the second line, we were able to list all the files in the current directory.

Now all that was needed was to traverse to the directory with a flag and read it, hence the following payload was used to traverse back and read the 

 file with a wildcard. It was confirmed that it was the only 

gave the You've Pwned it modal and the Flag.

The PoC involved putting the following payload on the input field.

The input contains two lines separated by a newline. The first line is 

 function, the regex checks each line separately. The first line fails the validation because it contains characters that aren't allowed by the regex. However, the second line 

 is a simple alphanumeric character that passes the regex validation. Because at least one line in the input satisfies the regex pattern, the entire input passes validation.

After passing validation, the application tries to read a file with the name. In Ruby's IO operations, when a filename begins with the pipe character |, Ruby treats everything after it as a command to execute and reads the output of that command instead of reading from a file. In this case, the command being executed is 

. This command traverses up two directories (from 

 files, including the flag file that contains the sensitive information we're targeting.

The output of this command is then passed to the ERB template engine and displayed to the user, revealing the contents of the flag file and completing the exploit. This combination of regex validation bypass and command injection through Ruby's IO special character handling creates a powerful vulnerability that allows attackers to execute arbitrary commands and read sensitive files.

The Flag as obtained from the application interface is

The impact of this vulnerability is critical. It allows attackers to execute arbitrary commands on the server, which can lead to complete compromise of the application and potentially the entire server. Attackers can access sensitive system files, steal confidential data, install malware, and potentially pivot to other systems in the network.

Dojo challenge #41 - Ruby treasure winners & writeup

Google dorking is a comparatively simple yet invaluable reconnaissance technique for ethical hackers to learn.

Suitably customised ‘dorks’ (Google searches that reveal sensitive information about targets) can uncover hidden admin panels, misconfigured subdomains and exposed credentials within minutes – all without sending a single direct scan. Master common Google dorking operators like 

 and this passive recon technique can provide intel that paves the way to finding hitherto overlooked vulnerabilities.

The power of Google dorking (aka Google hacking) was creatively demonstrated, for instance, by 

research about leveraging dorks to find zero-days

 from Suraj Khetani of Unit 42, which was a 

contender for PortSwigger’s web hacking techniques awards for 2017

This article will elaborate on the value of dorking to Bug Bounty hunters, and explain how to conduct dorking queries in a multitude of effective ways.

Why Google dorking is an essential skill for Bug Bounty hunters

Core Google dorking operators for passive reconnaissance

Basic Google dorking queries: hands-on examples

Best practices for preventing Google dorking attackss

Next steps: from passive recon to exploit development

Google dorking (aka Google hacking) leverages specialised search operators to uncover publicly indexed resources such as files, directories and login pages that organisations never intended to expose. Unlike active scanning techniques like web crawling or DNS brute-forcing, dorking is entirely passive – meaning that no trace of your activities is left on your target’s systems.

For Bug Bounty hunters, mastering Google dorking means covering more ground with less effort and identifying vulnerabilities other hunters might miss.

This recon method empowers ethical hackers to quickly gather high-quality, publicly available intelligence about target applications. Mastering Google search operators can usefully augment recon techniques like 

, and helps uncover exposed assets such as forgotten subdomains, misconfigured directories and sensitive files.

 serves as a particularly invaluable resource for staying up to date with evolving search techniques and attack vectors.

Below is a list of Google search operators commonly used in advanced dorking:

 - Displays Google's cached version of a page

 - Finds files of a specific type (e.g., PDF)

 - Searches within a specific website or domain

 - Finds pages with the term in the title

 - Finds pages with the term in the body text

 - All terms must appear in the body text

 - Filters news by source (used in Google News)

 - Finds pages with the term in anchor text

 - Acts as a wildcard for one or more unknown words

The YesWeHack Blog

‘AI slop’ bug reports and outsourcing triage, OpenPGP.js signature-spoofing bug, race to combat zero-day exploits – OffSec roundup for CISOs

‘AI slop’ bug reports and outsourcing triage, OpenPGP.js signature-spoofing bug, race to combat zero-day exploits – OffSec roundup for CISOs

Recon Series #6: Excavating hidden artifacts with Wayback Machine and other web-archive tools

Critical signature-spoofing vulnerability in OpenPGP.js hits the headlines

‘AI slop’ bug reports and outsourcing triage, OpenPGP.js signature-spoofing bug, race to combat zero-day exploits – OffSec roundup for CISOs

Dojo challenge #41 - Ruby treasure winners & writeup

Recon series #5: A hacker’s guide to Google dorking

Vulnerability prioritisation and validation: continuous threat exposure management (CTEM) series #2

Dojo challenge #41 - Ruby treasure winners & writeup

‘Airborne’ AirPlay attacks, netting $64k from deleted files, triaging AI slop – ethical hacker news roundup

Beyond ‘../../’ - a practical guide to path traversal and arbitrary file read attacks

Tackling vulnerabilities at source: How to cut the rising cost of DevSecOps

‘Airborne’ AirPlay attacks, netting $64k from deleted files, triaging AI slop – ethical hacker news roundup

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us