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 

 are used to normalise the path before access. On Windows, both slashes (

) are accepted, and applications may normalise them inconsistently.

Various programming languages introduce additional nuances:

, but developers often forget to validate the result.

, but path normalisation alone doesn’t guarantee security unless the final resolved path has been validated.

 (prior to 5.3.4) allowed null byte injection to bypass file extension constraints

 to normalise paths, but misuse leads to traversal bugs.

 and serverless frameworks may load files from cloud-mapped paths like 

, which becomes a critical read target if exposed.

Constructing a path securely requires resolving it to an absolute form, then comparing it to a known safe base directory. Simply checking for 

Path traversal often hides in features that seem harmless. Common vulnerable patterns include:

In APIs, traversal is common inside JSON parameters:

Or embedded into nested structures, especially in GraphQL:

Even with frontend validation, these inputs are often passed unvalidated to backend logic.

, but decoding behavior in proxies or application layers may allow functionally equivalent payloads.

: ..\\..\\ (works on Windows or with tolerant parsers)

These techniques become even more powerful when path values pass through multiple decoding layers – for example: Nginx -> Node.js -> Python.

To accelerate testing, use tools like ffuf with a custom wordlist:

Ffuf, which is written in Go, is a fast web fuzzer. The 

 (filter status code) option is used to ignore responses with specific HTTP status codes. In the example above, 

 filters out forbidden responses, freeing researchers up to focus on more relevant results.

Alternatively, we recommend leveraging predefined payload lists like those 

Be careful not to overload the server when fuzzing and, if you’re Bug Bounty hunting, always follow the program rules!

Path traversal is more likely to appear in JSON APIs than query strings. This is especially true for:

Export features that read templates or reports

File storage APIs (for instance S3 proxies)

Lambda functions that dynamically load files

Microservices fetching content on behalf of other services

Consider this real-world scenario involving an authenticated endpoint:

The application here was built on AWS Lambda with source code stored in 

. The endpoint rendered templates using the value of 

, which led to full source code disclosure.

In another case, a REST API offered an export route with filename control:

, the backend only validated extensions (ie .csv). A null byte bypass (

) allowed reading of the environment file, exposing live production secrets.

In some applications, when a user submits a request, the server doesn’t process it directly but instead 

 – often a private backend service not exposed to the public internet. This pattern is common in microservice architectures, where a gateway or frontend handles incoming client requests and then issues new internal requests.

This user-controlled request is parsed by the server, which extracts the 

 and internally forwards the request to an API endpoint – in this case: 

. The internal API then executes the request and returns a structured response:

This is where things get interesting. Since the server constructs the internal API path using user input, you could try injecting path traversal payloads. For example, instead of 

This would result in the server forwarding the request to:

Depending on path resolution, this might resolve to 

 – thereby bypassing routing restrictions and accessing an internal or privileged resource.

Even if the server doesn’t return the full response from the internal API, many applications still leak useful clues – status codes, success flags or generic messages like "Permission denied" – confirming that the backend request was executed and helping to signpost opportunities for further exploitation.

In more advanced cases, this internal API might have higher privileges or access to restricted endpoints. As with 

, you’re using the application as a proxy to hit internal services – but via path manipulation rather than URL control.

This kind of internal path traversal can become even more powerful when chained with bugs like IDOR (to identify valid resource paths) or misconfigured access control (to exploit internal roles or tokens). Ultimately, you’re not exploiting a file system directly – you’re hijacking the backend’s logic to navigate internal API routes in unintended ways.

Once user-controlled input is passed directly into a file access function without restricting it to a base directory, the attack surface expands far beyond directory traversal.

This kind of vulnerability doesn’t rely on 

 sequences. Instead, it stems from backend logic that blindly trusts a full user-supplied path, often within JSON APIs or internal tooling. You’re no longer escaping a path – you’re choosing which files to access, often without constraint.

In real-world cloud environments, this can lead to severe consequences. Applications running on AWS Lambda, Google Cloud Functions or Azure often store source code and credentials in predictable locations such as 

. Arbitrary read access to these paths can reveal:

Environment variables used for authentication

Temporary cloud credentials injected by the platform

Linux exposes a wealth of process information via the 

 discloses secrets injected into the runtime environment, while 

 can leak command-line flags passed to the application.

On web servers, arbitrary file read allows you to dump source code files, which may expose hardcoded secrets and unsafe code patterns. These insights often lead to higher-impact vulnerabilities.

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

Effective security operations (SecOps) obviously don’t generate revenues; instead they prevent potentially catastrophic harms, which remain hypothetical and hard to quantify unless they come to pass.

Whereas a bestselling product wins acclaim, the breach averted because a vulnerability was found and patched goes unnoticed.

In this sense, security – like taxes or insurance premiums – is often seen as “a cost of doing business”.

And this cost is rising as attack surfaces grow and threat actors become more sophisticated. Moreover, while CISOs’ burgeoning workload is 

, it seems that developer workloads and therefore development costs are also rising because of security requirements.

A 2024 report from market research firm IDC on ‘

Organisations were spending more than $28,100 per developer, per year for security tasks such as manual reviews and context switching

Developers on average estimated that 19% of their weekly working hours were spent on security-related tasks

Developers estimated that the number of hours they spent on security had increased by nearly two hours per week, year on year

Even with AI tools supercharging their productivity amid ever-more demanding release cycles, devs are also still spending an average of 3.6 hours a week addressing unexpected security issues outside of normal working hours – with all the adverse consequences for work-life balance and job dissatisfaction that might bring. This also reflects a reactive rather than proactive approach to security.

 that while share prices reliably fall following disruptive cyber-attacks, these are often short-lived and less severe than you might expect.

Might such findings, allied with the fatalistic sense that cyber-attacks are unavoidable, make it harder to secure necessary increases to security budgets?

CISOs will certainly not be complacent about what’s at stake as they grapple with 

, backed by the threat of enormous fines and even the spectre of them 

But it’s clear that security strategies and tooling that minimise development costs and disruption will strengthen their ability to secure buy-in from the boardroom.

To ease the security burden on developers, IDC has urged IT and software development team leaders to automate repetitive and time-consuming tasks, and ensure DevSecOps tools deliver accuracy with minimal false positives, integrate seamlessly with existing workflows, and offer clear, actionable insights for addressing security issues without unnecessary complexity.

Tackling the root causes of vulnerabilities

Bug Bounty Programs offer countless benefits – not least continuous testing and finding vulnerabilities missed by pentests – but among the most unsung is the opportunity to reduce the number of vulnerabilities that exist in the first place.

Vulnerability remediation increases developer workloads. Bug Bounty offers an opportunity to create a virtuous circle whereby devs can leverage vulnerability reports to learn how to avoid a recurrence of similar issues in the future. Consider how Orange France, a YesWeHack customer since 2019, 

intentionally leaves vulnerabilities reported by hunters on internally-accessible dummy websites

, for its employees to discover and learn from.

 appear in your code, our platform can help your SecOps function reduce time-to-fix with:

Standardised, actionable reports with easy-to-understand Proofs of Concept (PoCs), remediation recommendations, and descriptions of exploitability and potential impact

Triagers and hunters available to answer follow-up questions from developers and security teams

Risk-based prioritisation of the most critical vulnerabilities and less time wasted on false positives or low-impact issues

Integrations with tools like Jira and ServiceNow streamlines remediation workflows and makes it easier to track bug status and adhere to resolution targets

 of our Bug Bounty service and to find out more about how your organisation can supercharge vulnerability discovery, reduce time-to-fix and facilitate secure development practices.

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

 that has led to empty shelves has been described as a “

 to all organisations” by the UK National Cyber Security Centre. 🚨

Harrods, the luxury London department store has just become the 

 were also targeted. Marks & Spencer (or M&S) has suffered the most calamitous consequences. A suspected ransomware infection, which has been linked to the hacking collective Scattered Spider, has 

 and led to gaps on store shelves as well as disruption to loyalty scheme and gift card payments. The clothing, homeware and food retailer’s stock value has plummeted by around £650 million. Cybersecurity expert Graham Cluley 

 that “attacks involving the DragonForce ransomware” – the suspected virus involved – “

usually start with exploitation of known vulnerabilities

” – illustrating the importance once again of robust vulnerability identification and management and the prompt application of security patches. 🔒

SaaS systems ‘dismantle essential security boundaries’

An overreliance on the software-as-a-service (SaaS) model is “creating single points of failure with potentially catastrophic system-wide consequences”, according to the CISO of JPMorganChase. ⚠️

 to third-party suppliers, Patrick Opet also warned that “fierce competition among software providers” has incentivised “

rushed product releases without comprehensive security built in

”. In an excoriating critique, Opet said strict segmentation between internal resources and untrusted external interactions had been abandoned in favour of “unchecked interactions between third-party services and firms’ sensitive internal resources”. The security exec suggests rejecting “these integration models without better solutions” – or at least providing “continuous, demonstrable evidence that controls are working effectively, not simply relying on annual compliance checks.” 🛡️

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

The YesWeHack Blog

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

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

New Dojo sandbox environment for creating Ruby CTF challenges

Recon series #4: Port scanning – uncovering attack vectors by revealing open ports and hidden services

Dojo challenge #40 - Hacker profile winners & writeup

New Dojo sandbox environment for creating Ruby CTF challenges

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us