, challenged the participants to exploit a JavaScript prototype pollution to trigger a catch exception handler and execute arbitrary JavaScript code to capture the flag.

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 want to thank everyone who participated and reported to the Dojo challenge. 

There where a ton of great reports this time. 

You find the best write-up overall below:

The application allows a user to build a hacker profile combining the details of a random Profile (if all details of a hacker not provided) and the user input by the hacker. However, the application suffers from the prototype pollution and unsafe code evaluation. The vulnerable code path allows an attacker to modify JavaScript's Object prototype and inject malicious code that is subsequently executed via an 

 function. This occurs due to the improper validation or sanitization of the user-supplied JSON data. This vulnerability enables unauthorized access to sensitive information, including environment variables, and potential complete system compromise.

We are presented an application that allows a user to build a profile using the JSON input. A thorough code analysis was performed during the initial reconnaissance phase which revealed the underlying tech-stack. The application uses JavaScript, Node JS and EJS templating. Various utility functions are implemented to handle the user input and manage application.

The first step in analyzing the user input handling is to examine the entry point where the input is processed. In this case, the user input undergoes a transformation by a Web Application Firewall (WAF), which URL-encodes the input to mitigate any malicious payloads.

 function. This essentially reverses the encoding performed by the WAF, converting URL-encoded characters back to their original form. If the decoded input is empty (i.e., the user does not provide any input), the 

 variable is set to a default value of an empty JSON object (

). This ensures that the application always operates on a valid object. The decoded and validated input is then parsed using 

. This step implies that the input is expected to be a valid JSON string.

In the next step, a random Profile is selected with a 

 function call which selects a random profile from the 

 variable as provided in the set up code. The selected random profile is assigned to 

 method then combines the properties of the 

 input to create the final user object. It iterates over each key in the 

 is used instead. This method enables the user input to override default values, giving the attacker control over the profile's properties.

 method iterates over the keys of the user input and merges them with the target object. This raises concerns about potential prototype pollution, where an attacker could inject properties that affect the object’s prototype, potentially altering application behavior in unexpected ways.

Then comes the main block of the application logic. This code block attempts to convert all user properties to strings before rendering the template. It iterates through each property of the user object, handling dates specially by formatting them without the GMT timezone. If any error occurs during this process, the application enters an error handling path where it checks for debugging configuration. When debug mode is active, the application dangerously evaluates arbitrary code specified in 

, creating a potential execution point for attacker-controlled code. This means if an attacker can cause the 

 block to execute with a crafted payload, he can probably attain Remote code execution. The results are then passed to the template renderer.

After the initial analysis and an initial idea of what block of code could be vulnerable, we now proceed with how the application behaves with different inputs. Starting with the normal input with how the application is supposed to behave, it builds the normal hacker profile. The below is a screenshot with all the key-value provided as input.

 (incomplete details), the details get populated with a random profile from the set up code.

The goal was to identify and extract the 

 stored in an environment variable. Based on the analysis, the critical point was reaching the 

 block of the application, which contained insecure code execution via the 

 function. This was possible due to improper handling of user input and reliance on dynamic evaluation, where the 

 could be manipulated to execute arbitrary code.

To trigger the vulnerable path, we identified that prototype pollution was necessary. By manipulating the user input to include a property like 

, we could force an error in the string conversion process, specifically within this block:

 function, we observed that it recursively merges the user input with the default user object without proper safeguards. This allowed for unsafe property assignments, including critical keys like "constructor" or "proto," which are crucial for prototype pollution. This vulnerability could enable an attacker to inject properties that influenced the eval function and ultimately expose the FLAG. However on further inspection the WAF blacklist contained the keyword 

 meaning it couldn't be used on the payload.

To exploit the vulnerability, a payload was crafted that both causes prototype pollution and triggers an error in the code flow. The crafted payload is as follows:

" portion of the payload manipulates the global Object.prototype to add a debug property with 

 is a plain JavaScript object, it inherits from 

. By polluting the prototype, we can inject a 

 is set to null. This forces an error when the code attempts to call 

 block, and the application checks if debugging is active:

, retrieving the flag from the environment variable.

This executes the code that exposes the environment variable containing the flag and you've pawned it modal.

The proof of concept (PoC) involves injecting a JSON payload that causes prototype pollution and triggers an error in the application. The payload sets the 

 is called in the application code. This error activates the catch block, where the insecure eval() function executes the injected code from 

. The injected code retrieves the flag from the environment variable using 

The above payload resulted in the FLAG to display the log in the application UI as

The vulnerability presents a significant risk as it allows attackers to exploit prototype pollution to manipulate application behavior. By injecting malicious properties into object prototypes, attackers can alter critical application logic and trigger the execution of arbitrary code. The use of the insecure 

 function further amplifies this risk, as it allows an attacker to execute injected code, potentially leading to the exposure of sensitive information, such as environment variables (e.g., the flag in this case). This type of vulnerability can be used for remote code execution and data leakage, posing a severe threat to the application's security.

To remediate this vulnerability, sanitize user inputs to prevent prototype pollution, avoid using 

, and use safe alternatives for dynamic code execution. Implement object property filtering to block dangerous keys, and use trusted libraries for deep object merging. Regular security audits will help identify and address such issues early.

Dojo challenge #40 - Hacker profile winners & writeup

“Security by obscurity” is no longer a viable strategy in a world of internet-facing assets and expanding attack surfaces, attendees at a YesWeHack Bug Bounty Summit in Qatar were told.

Gaurav Kumar Sharma, assistant director for security architecture and planning at Ooredoo Qatar, was reflecting on the thought processes that led to a partnership between Ooredoo and YesWeHack. Serving 121 million customers with a variety of telecommunications services, Ooredoo had complex cyber, compliance and insurance risks to mitigate, he said. “From an insurance perspective this security control is very important for us,” he said of their Bug Bounty Programs.

When it came to hardening its eclectic mix of internet-facing assets, Gaurav continued, Ooredoo sought continuous, scalable testing, leaner vulnerability management processes, and access to a diverse range of offensive security skills.

As a candidate for helping the Qatari multinational achieve these goals, YesWeHack stood out by dint of its platform, operating model and end-to-end service, Gaurav recalled

Oreedoo always goes with best-of-breed solutions. I’m happy we went with YesWeHack,” he told the audience of security professionals gathered in Doha in September.

The YesWeHack partnership began in 2022 with private programs for Ooredoo’s three primary customer-facing assets. The scopes, comprising web, mobile and API assets, were tested in production environments with real world conditions (so web application firewalls and other protections were in place). A 

, which Gaurav said was a governance requirement and something demanded by investors, was also launched – enabling his team to benefit from the expertise of any security researchers worldwide.

The Bug Bounty Program had a fast start, with the first reports arriving within minutes of launch and dozens arriving within the first week. There were high severity and critical vulnerabilities among them. Gaurav detailed one critical bug where the hunter had achieved account takeover by manipulating an API’s reset password request to trigger a forged post request, which forwarded the new password to an email address under his control. This potentially calamitous flaw was found and fixed for the sum of $1,500.

Fortunately, Ooredoo and YesWeHack were well prepared for the fast start. YesWeHack’s triage team swiftly reproduced and assessed the vulnerabilities, Gaurav recalled, while Ooredoo’s existing process for handling vulnerabilities withstood the demands of the new testing medium. “Bug Bounty was just an additional input,” he said. That said, the experience did lead to improvements in their vulnerability management process, while the hunters’ findings generated actionable insights about their security tools.

A KPI review was conducted after the first few weeks, after which the security team opted to persist with black-box testing but increase testing coverage. They also resolved to make the 

 public by the end of the year – a goal they went on to achieve.

At the time of the presentation, around two years after the partnership had begun, 319 Bug Bounty reports had been closed, while the VDP had delivered 40 reports.

Echoing sentiments expressed in many of our 

, Gaurav urged his peers in other organisations to launch their own Bug Bounty Programs on a small scale, but to do so as soon as possible. Since Bug Bounty is inherently agile and adaptable, rules and scopes are readily finetuned post-launch, as programs grow.

However, Gaurav advised against starting a Bug Bounty Program before ensuring security, development and other affected teams understand their roles, perhaps with the help of an RACI (responsibility assignment matrix). Mindful of Ooredoo’s busy start, Gaurav also emphasised the importance of being ready to handle reports and mitigate bugs in a timely fashion from the get-go.

Otherwise, the launch process is reasonably straightforward, he insisted – so long as you have a clear idea of your testing goals and strategy. Your customer success manager (CSM) can support you a great deal in this regard.

Crowdsourcing their access to hacking skills had proven especially invaluable given it had hitherto been difficult to find testers with the right competences for Ooredoo’s multifarious technologies and use cases. “Pentests might involve just 2-3 consultants; here I have access to thousands of hackers who are ready to go,” said Gaurav.

Given their contribution, which also includes advising on and validating fixes, hunters’ happiness should be top priority for program managers, said the security exec: “Make sure your SLAs and KPIs are met. Sometimes hunters get frustrated if they don’t get rewarded on time because they’re working day and night to give something back.”

So far “YesWeHack is living up to our expectations,” enthused Gaurav, “because we’re getting certain things that we would not have [otherwise] managed with the resources we have.”

In particular, he appreciated “the always-on dashboard and real-time understanding of my threat exposure made possible by a continuous testing scenario”.

Year-round testing coverage was a huge boon given the pace of release schedules. “Things are changing very fast,” said Gaurav. “Every month or week there is some change in our services, so one pentest cannot be good enough.”

The speaker said this cost-effective and continuous testing layer freed up internal resources to test more specific scenarios or implement other compliance-oriented initiatives.

Notable time-saving benefits included automated risk-scoring and YesWeHack’s triage service, “so that burden is always offloaded to YesWeHack”. Gaurav said the triagers’ initial severity calculations were valuable, but that he also appreciated the fact that Ooredoo was given the final say on CVSS scores, given their exclusive knowledge about whether vulnerabilities were truly critical within the context of their environment.

The CSM team also brought value in terms of notifying Ooredoo of actionable developments and helping them handpick the right hunters.

In fact, Ooredoo would not have so rapidly launched their public program, which further increased the volume of findings, without this wide-ranking support from YesWeHack, insisted Gaurav.

‘Think about your strategy in a changing world’

Gaurav dismissed concerns about any supposed risks entailed by inviting freelance hackers to probe your digital assets. After all, all organisations have vulnerabilities, he pointed out. Either you recruit ethical hackers to help you identify and eliminate those attack vectors – or you leave malicious hackers to find them instead.

YesWeHack’s managing director, Rodolphe Harand, interjected to add that hunters are vetted and held liable for violations by the platform’s terms and conditions. Customers (or, on their behalf, CSMs) can also handpick hunters according to a variety of parameters, such as relevant skills, performance metrics (points awarded for their findings) or country/region, as well as monitor hunters with user agents or VPNs for extra peace of mind.

As his presentation approached its conclusion, Gaurav implored his fellow InfoSec decision-makers to “think about your strategy in a changing world. The world has moved on,” he said. “Organisations are investing more in resiliency because they know that attacks will happen.”

 for further details on rules, rewards and scopes.

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

 to schedule a demo with one of our experts.

‘Continuous testing and a real-time understanding of my threat exposure’ – Ooredoo exec on the benefits of Bug Bounty

The UK’s planned overhaul of legislation designed to protect critical national infrastructure (CNI) will apply to a wider range of sectors and introduce tough new incident reporting requirements.

These measures accord with a promise to align the Cyber Security and Resilience Bill, “where appropriate”, with the EU’s NIS 2 regulation, made in a 

 issued by the Department for Science, Innovation & Technology (DSIT) on 1 April.

 (PDF) in July 2024 shortly after the Labour government entered office, will supersede the EU’s Network and Information Systems (NIS) Regulations 2018. Although the 2018 NIS regulation was 

, the first NIS framework has continued to apply in the UK due to the country’s departure from the trading bloc in 2020.

The policy statement for the bill says it will draw on “insights we have gathered from our international partners, including valuable lessons from the European Union on the implementation of its NIS2 regime”.

The bill “will address the specific cyber security challenges faced by the UK while aligning, where appropriate, with the approach taken in the EU NIS 2 directive”. With Prime Minister Keir Starmer having declared growth his defining mission, the policy statement adds that “this strategic approach ensures we can be flexible and responsive to cyber threats in a proportionate way that balances the impact on business”.

Data centres, managed service providers in scope

Incident reporting obligations will, in alignment with NIS 2, require in-scope entities to notify relevant authorities of significant security incidents within 24 hours, and then submit a more detailed report within 72 hours.

Also mirroring NIS 2, the bill will bring managed service providers (MSPs) into scope, with the policy statement noting their “unprecedented access to clients’ IT systems, networks, infrastructure and data”.

 in September 2024, will also be in scope. Those above a certain capacity threshold will have to share information with authorities, and comply with obligations around risk management and “reporting significant incidents”.

Supply chain security will also become a focus of UK cyber law – another similarity to NIS 2 – through the mechanism of secondary legislation that will introduce new duties for operators of essential services (OES’) and relevant digital service providers (RDSPs). These duties will include “appropriate and proportionate measures [...] to prevent vulnerabilities in suppliers from undermining essential or digital services”. 

Regulators will also be empowered to “designate specific high-impact suppliers as ‘designated critical suppliers’ (DCS)”, which will be subject to “core security requirements and incident reporting obligations”.

Recognising the fast-evolving nature of cyber threats, the legislation will grant the DSIT Secretary of State powers to rapidly update regulations without needing fresh primary legislation.

While the policy statement repeatedly hints at less onerous business-friendly regulations, the need to minimise compliance burdens and facilitate cross-border cooperation and information-sharing will surely ensure a high degree of alignment with NIS 2.

NIS 2 has broadened the range of in-scope sectors

, divided them into “essential” and “important” categories, strengthened information-sharing measures, and introduced various measures for facilitating coordinated vulnerability disclosure (CVD).

To find out how YesWeHack can help you comply with UK and European cyber regulations, 

 of our Bug Bounty, vulnerability management and attack surface management platform.

UK publishes proposals for NIS 2-equivalent Cyber Security and Resilience Bill

Did you know that manipulating a single HTTP header can unlock high-impact security flaws hidden within a web application?

HTTP headers control how browsers and servers interact with data, so these vulnerabilities can affect the entire application stack.

In this comprehensive guide, we share techniques – both simple and advanced – for exploiting vulnerabilities in HTTP headers, ranging from abusing custom headers to leveraging cache poisoning and reverse proxy misconfigurations.

With real-world examples and easy-to-follow tips, this article will help you spot weaknesses faster and boost your Bug Bounty and ethical hacking skills.

Let's dive in and uncover how minor modifications to request headers can reveal major security issues!

CPDoS via Akamai: caching error responses

CPDoS on Cloudflare: infinite redirect loop

Common HTTP headers used by reverse proxies

General HTTP headers used by reverse proxies

Mitigation & best practices for HTTP header exploitation

Analysing HTTP response headers provides valuable information about the web application. Headers can reveal running services, software versions, and programming languages employed by the application. Such details help in tailoring payloads and selecting appropriate attack methods for further testing or direct HTTP header exploitation.

Inspecting custom HTTP headers in both responses and requests is a valuable first step when scanning a target. Customised headers often reveal sensitive information – such as internal system information or framework identifiers – or inadvertently expose pieces of code that can be leveraged for further reconnaissance.

An attacker can harness custom headers as keywords for open source intelligence (

) recon, potentially uncovering source code leaks and other technical information related to the application.

' responses, as they often expose headers that are not typically visible in server responses. These error responses often include default configurations as well as internal debugging information and naming conventions:

 can potentially retrieve fragments of source code that handle custom headers. For instance, source code in Github repos sometimes includes elements that interact with custom headers. So if you identified the header ‘X-Internal-Token: secret-value’, you could use Google to search (ie, dork) "X-Internal-Token" site:github.com”, which might then reveal hardcoded references in backend code, sample configs or .env files, or middleware or route handlers checking for the header.

 specifies which parts of the request message should be considered when creating a cache key. This mitigates attacks such as 

, where an attacker manipulates the cache to serve malicious content to other users.

 header values indicate whether a given user input is being trusted or reflected by the application. This may signal a potential attack surface for further testing.

As you can see above, the response contains the 

. Let’s leverage this information to test if the web application trusts user input:


Sure enough, the response confirmed that the 

 header is being reflected in the HTML and is likely being trusted by the application.

This discovery paves the way to using the 

 header to check for unexpected behaviours. Techniques such as 

 can potentially lead to cache poisoning. It might be possible to poison the cache if some responses use 

, the following setup can be combined with dictionary or brute-force attacks to extract hidden headers from the target:

Keep in mind that header-based fuzzing can sometimes produce 

 (CDN) and/or backend only respond differently under specific header configurations.

For example, a basic request using a simple Forwarded header may result in a normal response:

 header configuration does not work either, alternative configurations are available for testing against the application (see the 

In the example above, the forwarded header 

for=example.com;host=example.com;proto=https

. This allowed us to further experiment with the header’s value to determine the cause of the error, and later discover a

cache poisoning vulnerability affecting the application.

) is achieved when an attacker caches a malicious or malformed response that causes the legitimate page content to become inaccessible. Once stored in the cache, the poisoned response is served to all users attempting to access the affected resource – effectively resulting in a denial of service.

Let’s examine a real-world scenario where the cache error responses feature is enabled. By default, 

 edge servers cache error responses with status codes 

 for 10 seconds. However, this behaviour can extend to other status codes, depending on system configuration. 

If an attacker sends an invalid header – for example 

 – the server will typically return a 400 Bad Request error: 

When the cache error responses feature is enabled, this error response may be cached, resulting in CPDoS for other users regardless of whether their request is legitimate or not.

 caches certain HTTP response codes (200, 206, 301, 302, 303, 404, 410) with the Edge Cache TTL, unless overridden by Cache-Control or Expires headers. 

Cloudflare also uses the header X-Forwarded-Proto

 to determine the client's protocol version (HTTP vs HTTPS).

If a cached redirect accepts this header, it becomes possible to set the X-Forwarded-Proto header value to http. When the target detects this value, it attempts to redirect to the https version.

However, since our request was made using https, this manipulation causes Cloudflare to mistakenly interpret the request as http, resulting in a redirection back to https. This misconfiguration triggers an infinite redirect loop that eventually leads to a crash once the maximum number of redirects is reached. Given that Cloudflare typically caches 301, 302 and 303 responses, this attack method is frequently observed in web applications that utilise Cloudflare’s CDN.

Then on an HTTPS request, the backend may attempt to redirect to HTTPS again, causing an infinite redirect loop:

Because the redirect is cached, every user hitting that route may be trapped in a loop - eventually resulting in a browser error after too many redirects.

 cookie to differentiate between human and bot traffic. Automated tools are typically blocked quickly. However, misconfigured implementations can be vulnerable to the 

If an attacker supplies the misconfigured 

 cookie with a random or null value, the attacker could evade rate limits and potentially gain access to authenticated endpoints. I contacted 

 to confirm this behaviour and received the following response:

For those interested in bypassing techniques, I recommend reading our 

 article, which details advanced methods for circumventing firewall and filter protections in web applications.

Modern web architectures often implement several caching layers managed by different teams, and expose multiple cache headers in their HTTP responses. When caching is configured inconsistently, security vulnerabilities can arise through cache header collisions and inconsistent normalisation.

In the example below, a Drupal-based system uses two caching headers: 

 (proxy or VPN-level cache). When the page is successfully cached, these headers display a status of HIT; if not, they display MISS.

, confirming that the page had been cached, although the 

 header to our request, both headers were confirmed as cached (HIT), while the 

HTTP header hacks: basic and advanced exploit techniques explored

A voluntary code of practice designed to tackle the proliferation and irresponsible use of surveillance tech has so far been adopted by 22 states.

 (PDF) provides a framework for regulating the development, distribution, purchase and use of tools with commercial cyber intrusion capabilities (CCICs) – more commonly known as spyware.

Emerging from the ‘Pall Mall Process’, a British-French initiative 

, the accord was adopted at a conference in Paris last week. YesWeHack’s CEO and co-founder, Guillaume Vassault-Houlière, attended the event, as well as workshops held last year to discuss the proposals, to advocate for the robust protection of good-faith use of CCICs for security research purposes.

The Paris conference, which took place on 3 and 4 April, 

brought together 39 states, four international organisations

 and a broad coalition of representatives from civil society and the private sector, including the cybersecurity industry.

“Without international and meaningful multi-stakeholder action, the growth, diversification, and insufficient oversight across this market raises the likelihood of increased irresponsible targeting of a range of public and private targets, including journalists, human rights defenders and government officials, as well as critical national infrastructure,” reads the code of practice. “It also risks facilitating the spread of potentially destructive or disruptive cyber capabilities to a wider range of actors, including cyber criminals.”

Signatory states have volunteered to, among other measures, establish processes for banning CCIC vendors that engage in irresponsible behaviour, encourage CCIC vendors to prevent and mitigate the adverse human rights impact of CCICs, and consider human rights impacts when making export control licensing decisions.

However, the code of practice balances concerns about the risks posed by malicious use of these tools with an acknowledgement that their legitimate use must be protected. CCICs are used by security researchers, including in 

, in ways that – perhaps counterintuitively to those unfamiliar with ethical hacking – can help 

Mindful of this, the code of practice urges governments to establish or define “clear national policies on what constitutes legitimate use of CCICs in the context of cybersecurity (for example for penetration testing, red teaming and in relation to coordinated vulnerability disclosure policies and bug bounty programmes) and research for cybersecurity activities, aligned to existing protections or safeguards for cybersecurity researchers.”

Governments are also advised to encourage “commercial entities to establish and publish their own coordinated vulnerability disclosure processes, informed by existing international standards”.

The accord’s recommendations fall into four core pillars:

, such as applying export controls to prevent misuse and supporting victims of malicious use

, to clearly define lawful use of these tools, such as for national defence, cybersecurity or law enforcement; to coordinate internally across government bodies; and to train cybersecurity professionals to ensure responsible use and reporting

, to implementmechanisms that ensure state activities involving CCICs are transparent and subject to review

, includinginformation sharing among states, industry and civil society; establishing coordinated vulnerability disclosure practices; and implementing ‘Know Your Vendor/Customer’ requirements

Far from concluding the Pall Mall Process, the voluntary accord apparently represents a milestone in ongoing efforts to keep abreast of evolving and emerging threats – not least the threat of artificial intelligence supercharging the capabilities of CCICs.

“We intend to regularly review progress on the implementation of these voluntary good practices and on improving accountability across the market,” the code reads. “We resolve to keep this Code of Practice up to date with developments in the threat landscape.”

Signatories to the accord include: Austria, Denmark, Estonia, France, Germany, Ghana, Greece, Hungary, Ireland, Italy, Japan, Kosovo, Luxembourg, Moldova, Netherlands, Poland, Romania, Slovakia, Slovenia, Sweden, Switzerland and the United Kingdom.

 voluntary agreement over the same issue was signed in 2023 by 11 countries.

Persuading a wide range of nations to attend such conferences, let alone agree to common policies and enforcement mechanisms, is not easy. Spyware offers valuable intelligence capabilities – whether for national security or tackling terror threats – that some governments are reluctant to surrender. More than 80 countries have purchased spyware over the past decade, Britain’s intelligence agency

Spyware pact draws distinction between malicious and legitimate use of cyber-intrusion tools

GraphQL is an increasingly popular alternative to REST APIs, but its greater versatility also offers rich hacking opportunities.

For instance, the greater complexity of this query language creates scope for vulnerabilities with significant potential to expose significant volumes of sensitive data.

Moreover, popular use cases – such as mobile, SaaS and ecommerce applications as well as rapidly evolving software – mean that the organisations leveraging GraphQL sometimes have relatively significant financial resources.

Taken together, these observations mean that GraphQL vulnerabilities can sometime attract relatively significant rewards on Bug Bounty Programs.

This guide reveals practical techniques – from introspection queries to mutation manipulation – for identifying and exploiting GraphQL vulnerabilities and gaining an edge over your fellow bug hunters or pentesters.

Introspection Disabled? Try a fuzzing attack instead

Mitigation & best practices for GraphQL security

GraphQL is a powerful query language developed by Facebook and open-sourced in 2015. It allows clients to request exactly the data needed from an API in a single query, thus avoiding common REST API pitfalls like over-fetching or under-fetching. 

GraphQL can handle complex, nested queries and real-time data subscriptions, making it an ideal choice for modern web and mobile applications. (This 

 explains the difference in an amusing way).

The YesWeHack Blog

Dojo challenge #40 - Hacker profile winners & writeup

‘Continuous testing and a real-time understanding of my threat exposure’ – Ooredoo exec on the benefits of Bug Bounty

UK publishes proposals for NIS 2-equivalent Cyber Security and Resilience Bill

Dojo challenge #40 - Hacker profile winners & writeup

HTTP header hacks: basic and advanced exploit techniques explored

Spyware pact draws distinction between malicious and legitimate use of cyber-intrusion tools

Hacking GraphQL endpoints with introspection, query, mutation, batching attacks

HTTP header hacks: basic and advanced exploit techniques explored

EUCC cyber certification scheme enters early adopter phase after vulnerability disclosure rules issued

The art of payload obfuscation: how to mask malicious scripts and bypass defence mechanisms

Limitations are just an illusion – advanced server-side template exploitation with RCE everywhere

EUCC cyber certification scheme enters early adopter phase after vulnerability disclosure rules issued

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us