The number of new vulnerabilities discovered in 2024 jumped 38% year-on-year, reaching an all-time record of 40,009 new CVEs (Common Vulnerabilities and Exposures).

This compared to 28,818 CVE records published during 2023. To put this in perspective, this growth far outpaced even the rapid rate of increase since 2016, before which numbers had 

 for many years (see the chart below). Most remarkably, the total number of CVEs published last year accounted for 15.32% of all CVEs that have ever been published.

Since 2016, we’ve now seen a 520% rise in the annual volume of new CVE records, which catalogue publicly known vulnerabilities in software or hardware.

These trends are helpfully documented on 

, an open-source project managed by security researcher Jerry Gamblin.

So what changed around 2016-2017? And what drove the even sharper rise last year?

The most obvious factor driving the increase in vulnerabilities is the inexorable growth in the volume of code where vulnerabilities might lurk. Attack surfaces are ballooning amid growing adoption of cloud computing, IoT devices and edge computing, the persistence of legacy systems, and the ongoing digitisation of modern life generally. Software is also becoming more complex, broadening opportunities for finding security weaknesses.

And for all the praiseworthy efforts to make applications more secure-by-design (including security features such as 

 and wider adoption of DevSecOps development practices), hackers, both malicious and ethical, are getting more sophisticated at finding vulnerabilities. AI, specifically large-language models, has been a game-changing accelerant for innovations in vulnerability discovery and exploitation.

As well as more numerous, vulnerabilities are also potentially more impactful on account of the increased integration of third-party components. 

 are just three of many examples where upstream bugs have caused havoc downstream by affecting hundreds or thousands of applications or organisations.

In this context it’s understandable that organisations and regulators have woken up to the importance of vulnerability and discovery and management. Within the EU, 

 are three notable recent examples of legislation that mandates vulnerability disclosure and/or puts offensive security best practices front and centre. 

, from automated scans to pentests, red team exercises and 

Finally, vulnerability disclosure practices have become more standardised, streamlined and widely ingrained as best practice.

But do any of these trends account for the record CVE rise witnessed last year? Not according to Jerry Gamblin, who documents CVE trends on 

“This year's growth originated almost entirely from the top five CNAs [CVE Numbering Authorities],” he told YesWeHack. “These CNAs were specifically created to report CVEs for open-source projects like VulDB, Kernel.org, and GitHub, as well as for WordPress plugins such as Patchstack and Wordfence.

“Collectively, these five CNAs published 17,473 CVEs, making up 43.67% of all CVEs last year. Notably, the Kernel CNA is entirely new, having been founded in mid-February last year and publishing 4,325 CVEs, which is 10.81% of last year’s total CVEs.”

 revealed that 84% of analyzed codebases contained at least one known open-source vulnerability, with 74% harboring high-risk vulnerabilities – up from 48% in the previous year. Similarly, Patchstack has discussed the rise in WordPress flaws on its 

Hacking for €10k rewards and a secure open source ecosystem: Bug Bounty opportunities from the Sovereign Tech Fund


Whatever weighting you assign to the variables driving the multiyear increase in CVE numbers, one thing seems pretty clear: it seems unlikely we’ll see anything other than further rises for the foreseeable future. Indeed, FIRST (Forum of Incident Response and Security Teams) has 

 “another record-breaking year of CVE production” in 2025.

For CISOs navigating complex regulatory and threat landscapes, it only heightens the importance of increasing the effectiveness of their security testing and vulnerability management regime within the constraints of stagnating or only modestly increasing budgets.

Other notable stats about 2024 CVE trends to emerge from CVE.ICU:

, peaking in May, which accounted for 5,010 or 12.5% of the total, with 3 May the busiest single day with 824 new records

average CVSS (Common Vulnerability Scoring System) score was 6.67

, with 231 vulnerabilities achieving the highest-possible score of 10.0, and 

, a high severity buffer overflow issue in the Resource Reservation Protocol (RSVP) feature of Cisco IOS accounted for the 

highest number of unique vulnerable configurations 

, with 6,227 assignments (15.56%) (incidentally, this was also the most common CWE among bugs reported on YesWeHack, as the chart below shows)

most prolific five of all 433 CVE Numbering Authorities (CNAs) 

were: Patchstack (4,566 CWEs) Kernel.org (4,325), Wordfence (3,525), Vuldb (2,936) and Github (2,121) – all established to log CVEs for open-source projects or (in the case of Patchstack and Wordfence) focused on WordPress plugins

, which is inherently agile, continuous and scalable, is cost-effectively adding depth and breadth to the testing regimes of growing numbers of organisations. Combine a YesWeHack Bug Bounty Program with our 

 (ASM) product and you can continuously track your proliferating online assets, strategise your testing initiatives and prioritise vulnerability remediation based on vulnerabilities from various security testing channels – also including ASM auto-scans, traditional pentesting and Vulnerability Disclosure Policy (VDP). 

CVE surge: Why the record rise in new vulnerabilities?

, asked participants to perform a format string injection, read the system environment variables and reveal the flag.

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

 feeds to be notified of upcoming challenges.

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

TALKIE PWNII #3: VIDEO CHALLENGE WRITE-UP

We want to thank everyone who participated and reported to the Dojo challenge. Below is the best write-up overall:

The use of Externally-Controlled Format String vulnerability occurs when an attacker can control the format string used in functions like printf(), str.format(), or similar mechanisms. This can lead to unintended behavior, such as information disclosure, code execution, or crashes, depending on how the format string is handled.

When attempting to identify and exploit security flaws in an application, one of the most crucial steps is conducting a thorough analysis of the source code. A solid understanding of how the application works provides insight into potential attack vectors that might be vulnerable.

By carefully examining the code, you can identify areas where input from untrusted sources (such as user input or external systems) is processed. These inputs often serve as entry points for malicious actors to manipulate the application’s behavior.

The first lines of the code of the application (check below) give some information about the libraries that are used. It also shows that Jinja2 is used. Jinja2 is a template engine for the Python language used to render templates. In this case, it is used to render a template with the main HTML code of the application, but this part of the code is not really important in this case.

The next we can find in the code is the definition of the class 

, which contains a property and some methods that handles the 

Going step by step in the definitions of the 

, which is a python dictionary that contains 

. Data in python dictionaries are stored in 

 method, which is a constructor that will be automatically called when an object of the class is created.

. This method doesn't have much functionality, it just returns a value of a given product name but is not even used in the code of the application.

. This method handle the main functionality of the application.

The method expects a given argument called: 

First the application will check if this argument is empty, and if it is, it will return an empty string, otherwise, it will load the argument with the 

 library. This library is used for parsing TOML (Tom's Obvious, Minimal Language) configuration files. It provides a way to read and interpret 

 files directly into Python objects such as dictionaries. TOML is a 

 that is easy to read and write for humans. It is commonly used for configuration purposes in software projects.

 argument, it is also trying to access the key called 

 inside the given data and storing the content inside the 

With the given data stored in the variable 

, the application will check if there is a key called 

 inside the data and will verify if the value associated with this key is different from 

, the application will raise an error through the method 

 that we will analyze later in this post.

On the other hand, the application also validates if a 

 key exists on the given data and if its value is valid. This is done by checking if the value is inside the defined values at the 

 property previously analyzed. If both conditions are met, the application will return a string saying 

Your have selected: {item}. The gift is on its way!

program flow will go through the except definition

. This definition will save the program error in a variable called: 

 variable, the application will send this error to the 

 method and return the result of this call.

Finally, if none of the earlier conditions or exception handling blocks are met, the program flow will go through the last 

 in the below code. For example, one practical case could be: a valid wishlist is given, but expected keys are missing. This last flow will return the output of the 

The gift was lost among all the Christmas presents!

 previously mentioned. This method is used to create and return a 

, however, this creates a risk, as in Python is possible to 

access object properties through placeholders

. A placeholder in programming refers to a part of a string (or other data structure) that is temporarily used to represent a value that will be provided later. These placeholders are represented in Python as curly braces 

a="test"; mystring = "Hello {}".format(a)

 in this example, the variable mystring will have the value: 

 as the curly braces will be replaced with the 

 is included, it will refer to the current object instance, so if an attacker is able to inject curly braces with properties inside , it will be possible to format the message with internal data of the object. For example, 

 will be formatted with the value of the 

 property. This creates an attack vector that will be exploited later.

 class, few lines of code are left. This remaining code is used to load the user input in the application logic.

 method is called, giving as an argument the 

 POST parameter, and the returned value is saved at the 

 is compared to render the message returned in different ways; this is used to show the message with green colors when the request is successful and with red colors when some issue happens.

Having understood the application logic, we know that in order to use the application we need to send valid 

 standards and the application validations, a valid payload could be something like 

.This payload gives a successful response.

Now that we know how to send valid data to the application, we know there is a vulnerable function, the 

 one, so we need to find a way to give that function a malicious payload to exploit it.

 flow we analyzed previously, as it is sending the error to the 

 method. If we find a way to control what error is coming to this 

 flow we will be able to inject our payload there.

 flow, we will need some of the below lines of code to fail.

A good way to make the application crash will be with the 

 function, this function is used to convert a value into an integer number, so if we give it a random string with characters different that numbers it will crash, as it is supposed to work with numeric values. The best part of this crash is that python will include on the error our value given to the 

 function. With the following testing payload we can verify that: 

wishlist={"item"="hoodie","price"="test"}

As shown in the above image, we find a way to control the error sent to 

 method. Now we could access object properties and more by sending curly braces that will be formatted.

With the following payload it was possible to retrieve the 

wishlist={"item"="hoodie","price"="{.gifts}"}

With this injection it is possible to access internal data of the python code. As 

 library was imported, it was possible to access to the 

 property. The following payload was used: 

wishlist={"item"="hoodie","price"="{.__init__.__globals__[os].environ}"}

Internal environment variables were exposed and the FLAG was found: 

An attacker could exploit this vulnerability to disclose internal information like environment variables, object properties, code variables and more, creating a high impact on the confidentiality.

To fix this vulnerability several measures can be taken:

Implement a regex validation to price parameter to allow only numbers, so it will not crash.

Avoid direct user input in format strings

Sanitize user input to avoid curly braces be interpreted at the 

Dojo challenge #38 - Xmas wishlist, winners and writeup

The 24-month implementation window for the 

As of Friday (17 January), financial institutions operating within the EU had to be compliant with DORA, which obliges them to strengthen their cyber resilience across multiple domains.

There will inevitably be compliance stragglers, and regulators will likely be more forgiving of implementation gaps during the law’s early phase. And of course, compliance is an ongoing process rather than a milestone reached and then ignored. Even if regulators are satisfied, risks can always be further mitigated – and done so more cost-effectively.

The incentives for maintaining DORA compliance are significant: repelling 

 cyber-attacks against the sector, and avoiding fines of up to 2% of an organisation’s annual worldwide turnover or, for individuals found liable, €1 million.

With this in mind, here are five ways the YesWeHack platform – combining Bug Bounty Programs with Vulnerability Disclosure Policy, Pentest Management and Attack Surface Management solutions – can help financial service entities cost-effectively strengthen their alignment with the DORA framework.

#1 Continuous, in-depth and scalable testing

“Financial entities, other than microenterprises, shall ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions [as well as, with 

…] carry out at least every 3 years advanced testing by means of TLPT. [

“Central securities depositories and central counterparties shall perform vulnerability assessments before any deployment or redeployment of new or existing applications and infrastructure components, and ICT services supporting critical or important functions.”

 Unlike time-boxed pentests, Bug Bounty testing is continuous and easily optimised in line with budgets as well as the criticality and security level of assets in scope.

Tapping into our eclectic talent pool comprising tens of thousands of hunters can maximise testing coverage and harden assets in preparation for the Threat-Led Penetration Testing (TLPT) prescribed by DORA.

Crowdsourcing and results-oriented security testing helps organisations meet DORA’s demands for a rapid increase in cyber capacities amid a 

. This platform-driven approach also enables InfoSec teams to spin up new scopes or new programs quickly, which minimises software rollout delays.

And all this can be achieved cost-effectively, as organisations only pay for valid, actionable vulnerabilities.

#2 Support ICT risk management through comprehensive coverage

“Financial entities shall, on a continuous basis, identify all sources of ICT risk […]assess cyber threats and ICT vulnerabilities […] establish, maintain and review a sound and comprehensive digital operational resilience testing programme [that includes…] a range of assessments, tests, methodologies, practices and tools [that follows…] a risk-based approach […] duly considering the evolving landscape of ICT risk, any specific risks to which the financial entity concerned is or might be exposed, the criticality of information assets and of services provided […]”

 Combine our Bug Bounty and Attack Surface Management (ASM) products to continuously track your proliferating online assets, strategise your testing initiatives and prioritize vulnerability remediation.

 (CTEM) model, our ASM gives you a real-time, comprehensive picture of your online assets and exposure to known vulnerabilities, as well as automated, risk-based prioritisation of those bugs based on asset criticality and exploitability.

Better still, vulnerabilities from various security testing channels – including ASM auto-scans, Bug Bounty testing, traditional pentesting and Vulnerability Disclosure Policies (VDPs) – are standardised and managed through the same interface. The ASM’s ‘Asset Coverage’ feature brings insights on exposed assets that help security teams define and finetune their testing strategies in a structured, informed manner.

“Based on the conclusions from the internal audit review, financial entities shall establish a formal follow-up process, including rules for the timely verification and remediation of critical ICT audit findings.”

“Financial entities, other than microenterprises, shall establish procedures and policies to prioritise, classify and remedy all issues revealed throughout the performance of the tests and shall establish internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed.”

 As opposed to a manual approach that might use static deliverables and multiple, non-integrated tools, our platform-driven model reduces time-to-fix by enabling collaboration across teams, automating time-consuming processes, standardising vulnerability formats and integrating with organisations’ internal workflows. Remediation is also facilitated by our triagers’ and hunters’ prompt response to queries (YesWeHack’s average first response to new reports is just 5-6 hours).

“A dedicated ICT third-party risk strategy [should be] rooted in a continuous screening of all ICT third-party dependencies.”

“Financial entities shall identify all relevant underlying ICT systems, processes and technologies supporting critical or important functions and ICT services, including those supporting the critical or important functions which have been outsourced or contracted to ICT third-party service providers.”

 Our Bug Bounty service provides access to deep and broad testing skills that allow security teams to discover vulnerabilities not just in their own assets, but third-party components too. By integrating our ASM into their risk-management strategy too, organisations can continually identify potential weaknesses in third-party dependencies and throughout their whole supply chain.

“Management bodies should […] cultivate, at each corporate layer, and for all staff, a strong sense of awareness about cyber risks and a commitment to observe a strict cyber hygiene at all levels […] Allocate and periodically review the appropriate budget to fulfil the financial entity’s digital operational resilience needs in respect of all types of resources, including relevant ICT security awareness programmes and digital operational resilience training”

 Seamless collaboration between researchers, triagers, security teams and developers through a single, unified platform helps to break silos, increase security awareness internally and instil secure development practices. Consider how Orange France, 

according to its Bug Bounty Program Manager, Yann Desevedavy

, intentionally leaves vulnerabilities reported by our hunters on internally-accessible dummy websites. “Our employees then take on the role of ethical hackers to identify bugs that were previously discovered on our application,” said Yann. “It’s an engaging and effective awareness-raising activity.”

 of our Bug Bounty service or ASM, and to find out more about how your organisation can secure your growing attack surface cost-effectively.

How Bug Bounty and Attack Surface Management can help you comply with DORA

DORA now in force: 5 ways YesWeHack’s offensive security platform can bolster your Digital Operational Resilience Act compliance

We’ve learned a lot about CISOs’ priorities and challenges based on conversations with customers and the ‘hacktivity’ of our Bug Bounty platform.

As we celebrate our 10th anniversary, we’ve decided to share what we’ve observed in interviews with customers and hunters, along with tens of thousands of vulnerability reports they’ve resolved over the past 12 months.

Downloadable with a single click, our first-ever annual review of Bug Bounty trends is aimed at both hunters and security teams.

The drivers behind growing adoption of crowdsourced security testing worldwide

What 2024’s Bug Bounty stats – such as the most common CWEs and highest payouts – tell us about vulnerability trends and the Bug Bounty model

Interviews with our heads of triage and customer success management teams

Final leaderboards for 2024 and hacking advice from some of our highest performers – including our all-time #1 hunter

A recap of a record year for YesWeHack live hacking events

And the merits and challenges of leveraging Bug Bounty to secure open source

 without needing to enter your email or any other personal details.

The YesWeHack Bug Bounty Report 2025

Endpoint and parameter discovery are critical first steps in the Bug Bounty reconnaissance process. The real value lies in uncovering hidden endpoints, undocumented parameters and overlooked paths that expand the target’s attack surface. 

This guide will teach you practical techniques like parameter fuzzing, forced browsing, and path/parameter discovery, as well as how to use targeted wordlists, parse files and analyse JavaScript in order to find entry points for more rewarding vulnerability hunts.

Initiating reconnaissance: building your baseline

The first step in uncovering hidden endpoints and parameters is to establish a baseline understanding of your target’s exposed surface. Start by configuring Burp Suite for a manual crawl: enable the proxy to capture all traffic, and ensure JavaScript and CSS files are not blocked. Once this manual pass gives you a feel for the application’s structure, complement your findings with an automated Burp crawl. 

Scrape the robots.txt and sitemap.xml files for overlooked paths and use Google dorks. Also check out a related article we published recently, 

, to further enhance your parameter discovery process.

You’ll already start to have a clear, comprehensive view of your target.

Why JavaScript files are key for asset discovery

Modern web applications use JavaScript to manage user interactions, fetch data and shape site functionality. As a result, JavaScript files often hold critical insights that are neither visible in HTML nor easily guessable. For example, you may find references to specific API endpoints that a regular user would be unable to access through conventional means. Additionally, parameters that control feature flags or access testing endpoints might appear as variable names, function arguments or URL fragments inside these scripts.

Examining JavaScript source code helps you find undocumented APIs or parameters and understand how endpoints work. This context can enable more strategic testing – revealing which parameters are worth fuzzing, which routes are likely to handle sensitive data, and where misconfigurations might exist.

The following tools are invaluable for analysing JavaScript:

Using LinkFinder to find hidden endpoints and parameters

 is a Python-based tool that crawls JavaScript files and extracts URLs, paths and parameters that could otherwise remain unnoticed. Running LinkFinder is straightforward:

This command scans the specified JavaScript file and outputs a list of discovered endpoints directly in your terminal. You can then integrate these findings into your fuzzing tools, add them to your wordlists or explore them manually in Burp Suite.

JavaScript bookmarklets: handy, quick recon tools

For fast, on-the-fly endpoint discovery, JavaScript bookmarklets provide a lightweight, browser-native solution. A bookmarklet is simply a snippet of JavaScript code saved as a browser bookmark. When clicked on any webpage, it immediately runs within the browser and extracts valuable information – such as hidden endpoints – without requiring external tools or switching contexts.

This approach is particularly useful when you’re already exploring a target application and want to quickly expand your understanding of its attack surface. Instead of pausing to set up additional scripts or tools, you can instantly run a bookmarklet to uncover new paths or parameters as you navigate.

Here’s a great bookmarklet for extracting endpoints from JavaScript created by 

Add a new bookmark in your browser’s toolbar

Replace the bookmark’s URL with the JavaScript code snippet

Visit the target page and click the bookmarklet. The script will run in your browser, revealing previously undiscovered endpoints right on the page.

By incorporating bookmarklets into your reconnaissance toolkit, you can seamlessly integrate endpoint discovery into your browsing experience.

Burp Suite extensions for JavaScript analysis

While standalone tools and bookmarklets are powerful, integrating JavaScript analysis directly into your primary testing environment can streamline your workflow. By adding dedicated Burp Suite extensions, you can automatically detect hidden endpoints and parameters as you proxy requests through Burp, keeping all your reconnaissance data in one place.

 is a popular Burp extension that parses JavaScript files intercepted by Burp. It identifies and reports parameters and endpoints directly in your Burp dashboard.

burp extension, meanwhile, specialises in parsing JavaScript for interesting endpoints and values. GAP can highlight unusual behaviour or sensitive variables within the code.

 offers a comprehensive approach to JavaScript analysis, revealing endpoints, parameters and potential vulnerabilities.

Fuzzing involves systematically sending varied, often unexpected inputs – such as paths, parameters or HTTP headers – to an application’s endpoints. Unlike conventional scanners that stick to known routes and values, fuzzing deliberately explores the unknown. By experimenting with large sets of inputs, you can trigger edge cases, uncover functionality never intended for public use, and reveal subtle weaknesses in the application’s logic.

One form of fuzzing, forced browsing, discovers hidden directories, backup files and development endpoints that developers never intended to expose. While forced browsing targets the structure of an application’s environment, fuzzing can apply the same testing principles to parameters, headers and more complex areas of the application.

In the context of Bug Bounty reconnaissance, fuzzing isn’t simply guesswork. It involves leveraging well-crafted wordlists, selecting the right tools (such as ffuf or dirb), and using structured approaches offered by platforms such as Burp Intruder. This informed methodology ensures efficiency and precision, broadening your search for hidden directories, parameters and routes that could lead straight to overlooked vulnerabilities.

probing unlisted directories, files or endpoints to reveal backups, test areas or deprecated components.

 By testing for undocumented or unexpected parameters in application requests, researchers can uncover weaknesses in how applications handle input. Parameter fuzzing serves two key purposes: discovering new parameters that the application processes, such as hidden or undocumented GET and POST parameters, and exploring the potential values of these parameters to identify vulnerabilities like injection attacks, logic bypasses or insecure data handling. This dual approach makes parameter fuzzing a versatile and powerful technique in bug bounty reconnaissance.

Tweaking HTTP headers to discover server misconfigurations, debugging information or services running behind the scenes. This provides intelligence that can shape your subsequent attack strategies.

Why Is fuzzing crucial for asset discovery?

Fuzzing significantly expands the scope of your reconnaissance. Instead of limiting yourself to known pages or documented endpoints discovered previously, you cast a wider net over the target’s infrastructure, looking for anything that responds in an unexpected way. This broader perspective increases your chances of uncovering meaningful, hitherto undiscovered bugs. More specifically, fuzzing enables you to:

: Many web applications and APIs contain paths not linked in the user interface – like old admin panels, forgotten test endpoints or development scripts. Fuzzing systematically tests for these, catching assets that would be invisible through traditional navigation.

Identify misconfigurations or access control issues

: Sometimes, unexpected responses like HTTP status codes (eg, a 200 OK on a directory that should be restricted) signal a configuration slip-up. Fuzzing makes spotting these anomalies straightforward.

The YesWeHack Blog

CVE surge: Why the record rise in new vulnerabilities?

Dojo challenge #38 - Xmas wishlist, winners and writeup

DORA now in force: 5 ways YesWeHack’s offensive security platform can bolster your Digital Operational Resilience Act compliance

CVE surge: Why the record rise in new vulnerabilities?

The YesWeHack Bug Bounty Report 2025

Recon Series #1: Discover and Map Hidden Endpoints and Parameters

‘There are a lot of vulnerabilities on public programs’: pwnii’s Bug Bounty journey so far

The YesWeHack Bug Bounty Report 2025

‘Hacking is essentially about curiosity’: Blaklis on the art and science of Bug Bounty hunting

DOMPurify bypasses, prompt injecting ChatGPT to shell, AI fuzz finds – ethical hacker news roundup

Dojo challenge #37 - Hacker Forum winners and writeup

‘Hacking is essentially about curiosity’: Blaklis on the art and science of Bug Bounty hunting

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us