, 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

 - Searches for the exact phrase inside quotes

In this section, we'll dive into popular Google dorking techniques that can uncover valuable assets within your Bug Bounty target:

Subdomain enumeration is a key reconnaissance step for mapping an organisation's digital footprint. These searches for related subdomains should cover as much ground as possible in order to get a comprehensive view of your target’s infrastructure.

The simplest query for discovering subdomains is:

 Returns all subdomains of the target domain that Google has crawled and indexed.

 Expands the attack surface by revealing additional entry points that may have been overlooked during initial scoping.

You can also combine multiple operators with double quotation marks to discover subdomains with a specific keyword in the URL:

 Searching for all subdomains associated with google.com that include a specified keyword (‘developer’ in the above example) in the URL. This can either be in the hostname itself or in the endpoint.

 Uncovers development and staging environments, which typically have weaker security controls

 making them prime targets for initial compromise. These environments may contain debugging information, default credentials or unpatched vulnerabilities.

Discovering hidden files within domains can not only expose sensitive file content but also effectively fingerprint an application's programming language, framework or running services that are being used.

The following dork discovers filenames with a specified extension in order to determine the programming language:

 Identifies files with specific extensions across all subdomains, revealing the programming languages and frameworks in use.

 Understanding the technology stack helps researchers focus efforts on language-specific vulnerabilities and common misconfigurations.

Framework and content management system (CMS) detection

We can also look for files that reveal the use of specific frameworks and CMS platforms. The following Google dork identifies WordPress installs by finding google.com subdomains with a php file extension and ‘wp-’ keyword in the URL:

: Searches for content management system indicators within PHP files, specifically targeting WordPress, Drupal, and Joomla installations.

 CMS platforms have well-documented vulnerabilities. Dorks can identify which versions are running and help researchers determine if known CVEs apply to the target system.

Login interfaces represent critical security boundaries and are frequent targets for various attack vectors, with weak credentials or vulnerabilities enabling hackers to mount SQL, NoSQL, LDAP and other injection attacks.

 Locates authentication-related URLs across the target domain.

 Each login portal represents a potential attack vector for credential stuffing or injection attacks. Authentication weaknesses can be leveraged to obtain direct access to your target applications.

A more targeted query might for instance search for all google.com domains with the keyword ‘login’, the extension ‘jsp’, and the keywords ‘username’ and ‘password’ within the webpage, while ignoring URLs containing the keyword ‘assets’, which typically indicates template login files rather than real login pages:

 Identifies Java-based login forms containing username and password fields while filtering out static assets and template files.

 Login portals are prime contenders for compromising the system and this is a more precise, effective way to surface active or legacy login pages.

Exposed credentials, which can lead to immediate system compromise and privilege escalation, are always a high-impact Bug Bounty find. 

be careful not to leak or misuse any credentials uncovered.

The following dork searches for all google.com-related domains with the txt file extension and the password or credentials keyword in the URL, excluding results containing the readme.txt filename:

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

We all have to-do lists to triage and decisions to make over which outstanding tasks are most urgent. No one can do everything all at once.

In the world of vulnerability management, prioritisation is particularly tricky given what’s at stake and the lengthening queue of suspected vulnerabilities.

After all, security teams can typically patch only about 10% of known vulnerabilities in their environment each month, according to 

. This begs vital questions about what gets fixed first amid the 

shrinking time-to-exploitation of zero days

A model has emerged in recent years that can answer these questions, as well as offer visibility of the vulnerabilities that might exist and the terrain where they might lurk.

Adoption of this SecOps system, called continuous threat exposure management (CTEM), could lead to a 

, according to Gartner, which coined the CTEM term.

Focused on vulnerability prioritisation and validation, this is the second part of a series exploring the five phases of CTEM. We’ll explain how YesWeHack’s Attack Surface Management (ASM) product facilitates risk-based remediation with automated priority scores, helps to guide validation decisions, and broadens visibility of potential risk exposures by consolidating multiple sources for vulnerability discovery into a single, unified interface.

first part explained the first two steps, scoping and discovery

, which enable a real-time understanding of an organisation’s attack surface by systematically identifying all of its internet-facing assets – including systems the security team were not aware of due to shadow IT, misconfigurations or the siloed acquisition of tech. The next instalment will cover the final phase: mobilisation of resources to efficiently remediate validated vulnerabilities in order of priority.

An inevitable corollary of complex, expanding and fast-changing attack surfaces of course is an increase in vulnerabilities within those attack vectors.

Reflecting this trend, the number of new vulnerabilities discovered in 2024 jumped 38% year-on-year, reaching an 

With a burgeoning workload and hampered by the ongoing cyber-skills shortage, it’s unsurprising that security teams are struggling to remediate the security flaws they know about, let alone bring hidden bugs to light.

YesWeHack’s Attack Surface Management (ASM) solution supports security teams in implementing CTEM by helping them to prioritise the most critical vulnerabilities, as well as streamlining the vulnerability management process to ensure timely remediation of the rest.

The Prioritisation and validation phases follow SCOPING, where SecOps teams declare their domain names and IP ranges/addresses, and DISCOVERY, where our backend scanners detect related domains and subdomains, reachable services and associated technologies, then continuously detect any newly-surfaced online assets thereafter.

PRIORITISATION involves evaluating the urgency of ‘findings’ (suspected vulnerabilities) based on auto-generated priority scores.

Unlike standalone ASM platforms, our platform integrates vulnerabilities from multiple sources into a single, unified interface. These sources include:

Automated CVE scanning – drawn from a Vulnpedia module that is updated daily with in-the-wild vulnerability data, such as affected vendors, detection tools, public exploits and patches

Traditional pentesting via our Pentest Management product

Coming soon: Active Vulnerability Scanner within the ASM

Located in the Vulnerability Center with standardised formats and workflows, findings from all sources are consolidated into a single, unified view – providing a one-stop-shop for managing vulnerabilities.

Priority scores, which are automatically generated by a transparent, easy-to-understand algorithm, offer an accurate assessment of vulnerability risk within the context of the organisation’s environment. This saves SecOps teams time and empowers them to make the right decisions. They also retain ultimate control, since they can manually adjust scores to reflect their risk appetite and operational context.

The most widely used metric for evaluating a vulnerability’s threat level is of course the CVSS (Common Vulnerability Scoring System) score, which is determined by ease of exploitation, potential impacts and the potential for impacting other systems, among other variables.

Despite criticism from some quarters for 

oversimplification and misrepresenting real-world risks

, CVSS is a valuable metric. However, it does not tell the whole story.

That’s why our priority scores are based not just on CVSS but also in-the-wild exploitability and the affected asset’s criticality value.

In-the-wild exploitability is determined by the 

, which harnesses machine learning to analyse threat intelligence feeds, public exploit databases and correlations between past vulnerabilities.

The asset value, meanwhile, reflects the criticality of the asset where the vulnerability resides. This metric is generally higher if, for instance, it stores sensitive data, is a potential springboard into the wider network or if downtime would significantly disrupt the business and its customers. Asset value is set manually by the ASM customer because only they can truly understand the function and importance of the component or system in question.

The prioritisation algorithm provides invaluable insights for the next CTEM phase: VALIDATION, where SecOps teams manually confirm (or disconfirm) findings as exploitable (or not) within the context of their environment.

The EPSS score and asset value are particularly useful in judging whether a vulnerability poses a genuine security risk given:

Validation decisions can also be informed by engagements outside the ASM, such as:

And by testing the protections offered by firewalls, SIEM systems and the like

When findings are confirmed within our ASM, a vulnerability report is automatically generated for security teams to act upon.

A suite of other ASM features also empower SecOps teams to implement a unified, comprehensive and risk-based approach to security testing. This includes a dashboard affording a real-time overview of attack surface coverage and vulnerability exposure through multiple metrics and filters, such as filtering by priority score, charts showing ‘vulnerable assets by category’ and ‘top 5 most vulnerable assets’. Time-to-fix can be shortened meanwhile by integrating vulnerability reports into popular bug-tracking tools and tracking their status in real time with our connectors and public API.

Next up in this series is an examination of the final CTEM phase: MOBILISATION. After that we’ll publish a follow-up article exploring the synergy between Bug Bounty Programs and CTEM – with benefits including optimised testing coverage and cost-effective hardening of your exposed vectors.

 with YesWeHack today and discover how a risk-based approach can transform your organisation's security strategy.

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

earned a total of $64,350 from various Bug Bounty Programs

 after scanning tens of thousands of public GitHub repos for secrets hidden in past commits. “For each repository I restored deleted files, found dangling blobs and unpacked .pack files to search in them for exposed API keys, tokens, and credentials,” wrote Sharon Brizinov in a Medium post. Brizinov, who built a tool especially for the task, duly “discovered numerous deleted files containing API tokens, credentials, and even active session tokens that had not been revoked. Reporting these findings led to significant security improvements for the affected companies,” he added. The writeup, which was well received on r/netsec, was summarised in an X thread by the Critical Thinking podcast, in case you don’t have time to read Brizinov’s blog post. 🕵️

The next item on our monthly hunter roundup – first published as a 

 that, if abused, could enable attackers to 

spread malicious code from one infected device to another

. AirPlay enables iPhone and Macbook users to wirelessly stream music, photos and videos and ‘mirror’ the source-device screen to other Apple devices or third-party speakers and TVs.📺 The Oligo researchers who discovered the bugs dubbed them ‘Airborne’ vulnerabilities as they enabled attacks mounted via wireless networks or peer–to-peer connections. These vulnerabilities could lead to zero-click and one-click RCE, access control list (ACL) and user interaction bypasses, local arbitrary file reads, sensitive information disclosure, man-in-the-middle (MITM) attacks and denial of service (DoS). Despite a characteristically prompt fix from Apple, 

 that “given how rarely some smart-home devices are patched, it’s likely that these wirelessly enabled footholds for malware, across many of the hundreds of models of AirPlay-enabled devices, will persist for years to come. 🍏

 are making bug bounty triage harder, wasting maintainer time, and straining trust in vulnerability disclosure programs,” 

, head of content marketing at Socket, a security platform aimed at developers. She referenced a real-world bug report for Curl that was superficially convincing but cited non-existent functions and methods and fake patches. A software engineer at Open Collective, which manages its own program, recently complained that “

”, suggesting the indundation might ultimately force them to migrate to a Bug Bounty platform that can triage reports on their behalf. 🤖

examination of browser mitigations around cross-origin requests

Security Cross-Site Websocket Hijacking (CSWSH)

 harder to exploit is worth a read given it 

, which is open only to truly “novel web security research”. Analysis of these mitigations is “explored together with three case studies of past findings, investigating which of the attacks still work today,” wrote Tennant. 💡

Before we conclude with the latest hunter-focused content from YesWeHack (including a new Dojo feature, new public program, and new recon guide) here’s the final research rundown:

One-Click RCE in ASUS’s Preinstalled Driver Software

How a Single Line Of Code Could Brick Your iPhone

Guilherme Rambo on earning a $17,500 bounty

Drag and pwnd: Exploiting VS Code with ASCII

Fuzzing WebSockets for Server-Side Vulnerabilities

Python Dirty Arbitrary File Write to RCE via Writing Shared Object Files Or Overwriting Bytecode Files

Did you know: Ruby, where nearly everything is an object – even integers, nil, true and false – was created by Japanese programming legend 

, who blended his favourite parts of Perl, Smalltalk and Lisp. The song ‘Ruby’ by rock band the Kaiser Chiefs, meanwhile, is not a paean to the coding language or even an ex-girlfriend, but apparently named after the songwriter’s eponymous black labrador.🎸 Anyway, this is an unnecessarily elaborate preamble to the fact that YesWeHack’s 

! Naturally our latest monthly challenge – 

 – is based on this mature, still relatively common language with a history of interesting vulnerabilities. 💎

 discusses the previous, community-created Dojo Challenge, ‘Hacker Profile’, which involved server-side prototype pollution in Node.js: 🎙️

 helps you map attack surfaces by identifying open ports and which services are running – a crucial step before getting down to the business of bug-hunting. If you’re unfamiliar with the basics, then check out the 

fourth instalment of our recon fundamentals series

, which explains various passive and active port-scanning techniques and how to execute them with Shodan, Censys, Nmap, Masscan and Naabu.🌐

 for hunters to target: this time it’s 

, a payments platform offering a dozen assets in scope, grey-box testing with sandbox access and rewards up to $3,000 for critical vulnerabilities and $1,500 for high severity flaws 

 time now and we’d like to salute the achievements of 

, an Italian hunter who has climbed to fifth place for the 

 we conducted with the hunter last year, he attributed his success above all to persistence, as well as curiosity and a passion for hacking.🚀 Credit is also due to 

, up to bronze medal position for Q2 and now an impressive all-time rank of 59 having only joined in 2024. Another one to watch on the Q2 leaderboard below: 

, a Spain-based hacker who only joined last year, has risen to sixth and recently earned a ‘Black Hole’ achievement for netting the highest possible bounty on a program.👏

We’ll conclude, as we always do, with a list of 

 where you can meet the YesWeHack team, score some YesWeHack swag, and learn about bug hunting on our platform (or in one case learn about exploiting syntax confusions):

 – Singapore, 22-23 May, Bug Bounty Kampung (Village)

– Online, 22-23 May. We’re sponsoring this conference, while our in-house hunter Brumens will deliver a talk on ‘The Minefield Between Syntaxes: Exploiting Syntax Confusions in the Wild’ on 23 May, 1:25pm PST

, Clermont-Ferrand, 17-18 June, booth 125

More conferences and live hacking events will be announced in due course! 📅

Read this monthly roundup of content aimed at ethical hackers even sooner by subscribing to 

Are you a CISO, other security professional or security-conscious dev? Check out our CISO-focused sister newsletter, 

 – bringing you news, insights and inspiration around offensive security topics like Bug Bounty, vulnerability disclosure and management, pentest management and attack surface protection.

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

Ever tested a file download or preview endpoint and wondered if it could leak more than just the files it was supposed to serve?

Path – or directory – traversal vulnerabilities can expose passwords or secret tokens, source code and internal endpoints. Often leading to arbitrary file reads, exploits for these flaws can achieve significant impacts and Bug Bounty rewards.

In this article, you’ll learn how to detect and exploit path traversal in APIs, bypass sanitisation filters using encoding tricks, and escalate to internal path traversal by abusing server-side request forgery (SSRF) vulnerabilities or misconfigured proxies. We’ll also explore the mechanics of file resolution across different platforms and frameworks, discover the most valuable file targets for exploitation, and see how chaining traversal with other bugs can increase the impact of your exploits – and your Bug Bounty payouts.

Internal path traversal via internal API forwarding

From read to execution: how file access turns critical

Mitigations and defences against path traversal

Path traversal occurs when user input is used to build file paths without proper sanitization. This allows you to use 

 sequences to “traverse” directories and escape the intended path scope. By doing so, you can reach files that are outside the allowed directory – including sensitive configuration files, credentials and application source code.

For example, if the application serves files by appending a query parameter to a base path…

…could access the Unix password file, if the application doesn’t properly validate the resulting path.

The severity of the issue depends on which files are exposed and whether they contain secrets or code. But in many Bug Bounty scenarios, reading 

 is enough to escalate access or pivot deeper into the system.

To exploit traversal reliably, it’s important to understand how file resolution works at the OS and language level. On Unix systems, 

 is interpreted literally by the filesystem, and functions like 

The YesWeHack Blog

Dojo challenge #41 - Ruby treasure winners & writeup

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

UK retail cyber-attacks a ‘wake-up call’, SaaS overreliance ‘creating single points of failure’, calls for global regulatory alignment – OffSec roundup for CISOs

Middleware mayhem, Zoolander banter PoC, Malta to pardon hackers over ‘unfair’ charges – ethical hacker news roundup

New Dojo sandbox environment for creating Ruby CTF challenges

UK retail cyber-attacks a ‘wake-up call’, SaaS overreliance ‘creating single points of failure’, calls for global regulatory alignment – OffSec roundup for CISOs

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us