, 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

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 

 that documents his and Edoardo Geraci’s discovery.

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

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

The YesWeHack Blog

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

Dojo challenge #41 - Ruby treasure winners & writeup

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

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

Dojo challenge #41 - Ruby treasure winners & writeup

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

‘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

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

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

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

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

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us