Psychic Signatures - what you need to know
On April 19th 2022, Neil Madden disclosed a vulnerability in Oracle Java 15 through 18, and OpenJDK 15, 17, and 18. The vulnerability lies in the cryptography for ECDSA signatures, which allows an attacker to bypass signature checks entirely for these signatures.
It’s easy to see headlines about this vulnerability and skim right past them given the obscure nature of ECDSA signatures. However, ECDSA signatures actually play a key role in protecting systems across the internet for critical tasks like authentication.
Before we dive into details, if you want to experience how hackers exploit Psychic Signatures in a hands-on way. Jump straight into our free lab - Missions to try it out yourself.
What’s the big deal with ECDSA?
You may not have heard of ECDSA before. It’s the short name for Elliptic Curve Digital Signature Algorithm, which is a type of cryptography that makes use of the mathematical properties of elliptic curves, offering some of the strongest cryptographic security in the industry at the moment.
This means that it’s used for a lot of important functions, like:
- The signing of SSL certificates
- Handshakes during encrypted communications
- SAML
- JWT signatures
- OpenID Connect signatures
This means that ECDSA is a key part of many of the most sensitive functions for protecting systems out there. The ability to bypass signature checks would be potentially quite devastating.
How is the vulnerability exploited?
The mathematics of ECDSA is somewhat complicated, unfortunately. But the key thing to know is that an ECDSA signature contains 2 pieces of information: r, and s.
These numbers are used to calculate the validity of the signature. The value r is the “result” (left side) of a calculation using both r and s on the right side of the equation. Given that multiplying by 0 is a bad idea, the ECDSA specification explicitly calls out that if the value of r or s is ever 0, they should be discarded.
But the Java implementation of ECDSA forgot to take this into account. As such, it will accept a signature with both r and s is 0, which will always be true. We can demonstrate this with an example of a JWT, showing just how easy it is. Using https://token.dev/, we can generate a token with the algorithm ES256, similar to one that would be generated by an application:

Recall that a JWT is split up into 3 parts:
- Header (in blue)
- Payload (in green)
- Signature (in red)
Now, if we wanted to bypass the signature check, how would we go about this? The signature specifies the values for r and s, and is encoded in the DER format.

Let’s change our JWT to use this new signature. Note that in JWTs, the equal sign is not included.

Now, our signature has r and s set to 0, and in vulnerable versions of Java the signature check will now succeed for any payload you specify.
Who’s affected, and how to mitigate it?
The vulnerability affects both Oracle Java and OpenJDK. These include:
Oracle Java SE (And older, non-supported versions):
- 18
- 17.0.2
Oracle GraalVM Enterprise Edition:
- 22.0.0.2
- 21.3.1
OpenJDK:
- 18
- 17.0.2
- 15.0.6
- 13.0.10
- 11.0.14
- 8u322
- 7u331
Both Oracle and OpenJDK have put out advisories, and patches for the issue that can be applied right away.
Hands-on practices to defend against this vulnerability
Here at Secure Code Warrior, we strive to provide developers the most relevant information and hands-on exercises for critical vulnerabilities, whether it is a latest one like Psychic Signatures or something that’s been around for years.
We believe that, to truly keep risk at bay, it is necessary to enable developers to understand the defense mechanism and write secure code from the start. That’s why we create a step-by-step walkthrough of this vulnerability (and many others) for you and the teams that are impacted.
In the walkthrough, you will be able to follow the instruction to exploit the Physic Signature in JWTs and see the impact to a functioning app in real-time.
Try it out now.


Psychic Signature vulnerability lies in the crypto for ECDSA signatures, which protects systems for critical tasks like authentication. Hackers can bypass any signature check with this vulnerability. We will explain what it is and how to mitigate it in this post.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo

On April 19th 2022, Neil Madden disclosed a vulnerability in Oracle Java 15 through 18, and OpenJDK 15, 17, and 18. The vulnerability lies in the cryptography for ECDSA signatures, which allows an attacker to bypass signature checks entirely for these signatures.
It’s easy to see headlines about this vulnerability and skim right past them given the obscure nature of ECDSA signatures. However, ECDSA signatures actually play a key role in protecting systems across the internet for critical tasks like authentication.
Before we dive into details, if you want to experience how hackers exploit Psychic Signatures in a hands-on way. Jump straight into our free lab - Missions to try it out yourself.
What’s the big deal with ECDSA?
You may not have heard of ECDSA before. It’s the short name for Elliptic Curve Digital Signature Algorithm, which is a type of cryptography that makes use of the mathematical properties of elliptic curves, offering some of the strongest cryptographic security in the industry at the moment.
This means that it’s used for a lot of important functions, like:
- The signing of SSL certificates
- Handshakes during encrypted communications
- SAML
- JWT signatures
- OpenID Connect signatures
This means that ECDSA is a key part of many of the most sensitive functions for protecting systems out there. The ability to bypass signature checks would be potentially quite devastating.
How is the vulnerability exploited?
The mathematics of ECDSA is somewhat complicated, unfortunately. But the key thing to know is that an ECDSA signature contains 2 pieces of information: r, and s.
These numbers are used to calculate the validity of the signature. The value r is the “result” (left side) of a calculation using both r and s on the right side of the equation. Given that multiplying by 0 is a bad idea, the ECDSA specification explicitly calls out that if the value of r or s is ever 0, they should be discarded.
But the Java implementation of ECDSA forgot to take this into account. As such, it will accept a signature with both r and s is 0, which will always be true. We can demonstrate this with an example of a JWT, showing just how easy it is. Using https://token.dev/, we can generate a token with the algorithm ES256, similar to one that would be generated by an application:

Recall that a JWT is split up into 3 parts:
- Header (in blue)
- Payload (in green)
- Signature (in red)
Now, if we wanted to bypass the signature check, how would we go about this? The signature specifies the values for r and s, and is encoded in the DER format.

Let’s change our JWT to use this new signature. Note that in JWTs, the equal sign is not included.

Now, our signature has r and s set to 0, and in vulnerable versions of Java the signature check will now succeed for any payload you specify.
Who’s affected, and how to mitigate it?
The vulnerability affects both Oracle Java and OpenJDK. These include:
Oracle Java SE (And older, non-supported versions):
- 18
- 17.0.2
Oracle GraalVM Enterprise Edition:
- 22.0.0.2
- 21.3.1
OpenJDK:
- 18
- 17.0.2
- 15.0.6
- 13.0.10
- 11.0.14
- 8u322
- 7u331
Both Oracle and OpenJDK have put out advisories, and patches for the issue that can be applied right away.
Hands-on practices to defend against this vulnerability
Here at Secure Code Warrior, we strive to provide developers the most relevant information and hands-on exercises for critical vulnerabilities, whether it is a latest one like Psychic Signatures or something that’s been around for years.
We believe that, to truly keep risk at bay, it is necessary to enable developers to understand the defense mechanism and write secure code from the start. That’s why we create a step-by-step walkthrough of this vulnerability (and many others) for you and the teams that are impacted.
In the walkthrough, you will be able to follow the instruction to exploit the Physic Signature in JWTs and see the impact to a functioning app in real-time.
Try it out now.

On April 19th 2022, Neil Madden disclosed a vulnerability in Oracle Java 15 through 18, and OpenJDK 15, 17, and 18. The vulnerability lies in the cryptography for ECDSA signatures, which allows an attacker to bypass signature checks entirely for these signatures.
It’s easy to see headlines about this vulnerability and skim right past them given the obscure nature of ECDSA signatures. However, ECDSA signatures actually play a key role in protecting systems across the internet for critical tasks like authentication.
Before we dive into details, if you want to experience how hackers exploit Psychic Signatures in a hands-on way. Jump straight into our free lab - Missions to try it out yourself.
What’s the big deal with ECDSA?
You may not have heard of ECDSA before. It’s the short name for Elliptic Curve Digital Signature Algorithm, which is a type of cryptography that makes use of the mathematical properties of elliptic curves, offering some of the strongest cryptographic security in the industry at the moment.
This means that it’s used for a lot of important functions, like:
- The signing of SSL certificates
- Handshakes during encrypted communications
- SAML
- JWT signatures
- OpenID Connect signatures
This means that ECDSA is a key part of many of the most sensitive functions for protecting systems out there. The ability to bypass signature checks would be potentially quite devastating.
How is the vulnerability exploited?
The mathematics of ECDSA is somewhat complicated, unfortunately. But the key thing to know is that an ECDSA signature contains 2 pieces of information: r, and s.
These numbers are used to calculate the validity of the signature. The value r is the “result” (left side) of a calculation using both r and s on the right side of the equation. Given that multiplying by 0 is a bad idea, the ECDSA specification explicitly calls out that if the value of r or s is ever 0, they should be discarded.
But the Java implementation of ECDSA forgot to take this into account. As such, it will accept a signature with both r and s is 0, which will always be true. We can demonstrate this with an example of a JWT, showing just how easy it is. Using https://token.dev/, we can generate a token with the algorithm ES256, similar to one that would be generated by an application:

Recall that a JWT is split up into 3 parts:
- Header (in blue)
- Payload (in green)
- Signature (in red)
Now, if we wanted to bypass the signature check, how would we go about this? The signature specifies the values for r and s, and is encoded in the DER format.

Let’s change our JWT to use this new signature. Note that in JWTs, the equal sign is not included.

Now, our signature has r and s set to 0, and in vulnerable versions of Java the signature check will now succeed for any payload you specify.
Who’s affected, and how to mitigate it?
The vulnerability affects both Oracle Java and OpenJDK. These include:
Oracle Java SE (And older, non-supported versions):
- 18
- 17.0.2
Oracle GraalVM Enterprise Edition:
- 22.0.0.2
- 21.3.1
OpenJDK:
- 18
- 17.0.2
- 15.0.6
- 13.0.10
- 11.0.14
- 8u322
- 7u331
Both Oracle and OpenJDK have put out advisories, and patches for the issue that can be applied right away.
Hands-on practices to defend against this vulnerability
Here at Secure Code Warrior, we strive to provide developers the most relevant information and hands-on exercises for critical vulnerabilities, whether it is a latest one like Psychic Signatures or something that’s been around for years.
We believe that, to truly keep risk at bay, it is necessary to enable developers to understand the defense mechanism and write secure code from the start. That’s why we create a step-by-step walkthrough of this vulnerability (and many others) for you and the teams that are impacted.
In the walkthrough, you will be able to follow the instruction to exploit the Physic Signature in JWTs and see the impact to a functioning app in real-time.
Try it out now.

Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoOn April 19th 2022, Neil Madden disclosed a vulnerability in Oracle Java 15 through 18, and OpenJDK 15, 17, and 18. The vulnerability lies in the cryptography for ECDSA signatures, which allows an attacker to bypass signature checks entirely for these signatures.
It’s easy to see headlines about this vulnerability and skim right past them given the obscure nature of ECDSA signatures. However, ECDSA signatures actually play a key role in protecting systems across the internet for critical tasks like authentication.
Before we dive into details, if you want to experience how hackers exploit Psychic Signatures in a hands-on way. Jump straight into our free lab - Missions to try it out yourself.
What’s the big deal with ECDSA?
You may not have heard of ECDSA before. It’s the short name for Elliptic Curve Digital Signature Algorithm, which is a type of cryptography that makes use of the mathematical properties of elliptic curves, offering some of the strongest cryptographic security in the industry at the moment.
This means that it’s used for a lot of important functions, like:
- The signing of SSL certificates
- Handshakes during encrypted communications
- SAML
- JWT signatures
- OpenID Connect signatures
This means that ECDSA is a key part of many of the most sensitive functions for protecting systems out there. The ability to bypass signature checks would be potentially quite devastating.
How is the vulnerability exploited?
The mathematics of ECDSA is somewhat complicated, unfortunately. But the key thing to know is that an ECDSA signature contains 2 pieces of information: r, and s.
These numbers are used to calculate the validity of the signature. The value r is the “result” (left side) of a calculation using both r and s on the right side of the equation. Given that multiplying by 0 is a bad idea, the ECDSA specification explicitly calls out that if the value of r or s is ever 0, they should be discarded.
But the Java implementation of ECDSA forgot to take this into account. As such, it will accept a signature with both r and s is 0, which will always be true. We can demonstrate this with an example of a JWT, showing just how easy it is. Using https://token.dev/, we can generate a token with the algorithm ES256, similar to one that would be generated by an application:

Recall that a JWT is split up into 3 parts:
- Header (in blue)
- Payload (in green)
- Signature (in red)
Now, if we wanted to bypass the signature check, how would we go about this? The signature specifies the values for r and s, and is encoded in the DER format.

Let’s change our JWT to use this new signature. Note that in JWTs, the equal sign is not included.

Now, our signature has r and s set to 0, and in vulnerable versions of Java the signature check will now succeed for any payload you specify.
Who’s affected, and how to mitigate it?
The vulnerability affects both Oracle Java and OpenJDK. These include:
Oracle Java SE (And older, non-supported versions):
- 18
- 17.0.2
Oracle GraalVM Enterprise Edition:
- 22.0.0.2
- 21.3.1
OpenJDK:
- 18
- 17.0.2
- 15.0.6
- 13.0.10
- 11.0.14
- 8u322
- 7u331
Both Oracle and OpenJDK have put out advisories, and patches for the issue that can be applied right away.
Hands-on practices to defend against this vulnerability
Here at Secure Code Warrior, we strive to provide developers the most relevant information and hands-on exercises for critical vulnerabilities, whether it is a latest one like Psychic Signatures or something that’s been around for years.
We believe that, to truly keep risk at bay, it is necessary to enable developers to understand the defense mechanism and write secure code from the start. That’s why we create a step-by-step walkthrough of this vulnerability (and many others) for you and the teams that are impacted.
In the walkthrough, you will be able to follow the instruction to exploit the Physic Signature in JWTs and see the impact to a functioning app in real-time.
Try it out now.
Table of contents

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Quests: Industry leading learning to keep developers ahead of the game mitigating risk.
Quests is a learning platform that helps developers mitigate software security risks by enhancing their secure coding skills. With curated learning paths, hands-on challenges, and interactive activities, it empowers developers to identify and prevent vulnerabilities.
Resources to get you started
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
The Decade of the Defenders: Secure Code Warrior Turns Ten
Secure Code Warrior's founding team has stayed together, steering the ship through every lesson, triumph, and setback for an entire decade. We’re scaling up and ready to face our next chapter, SCW 2.0, as the leaders in developer risk management.