[GHSA-mpmc-qchh-r9q8] Altcha Proof-of-Work obfuscation mode cryptanalytic break

[ovx]

Updates

• Affected products

Comments
Requesting withdrawal.

The reported issue misclassifies ALTCHA’s obfuscation mode as a vulnerability. ALTCHA’s documentation explicitly states that obfuscation uses a proof-of-work + symmetric AES mechanism not for strong cryptographic secrecy but only to raise the bar against automated scraping by bots.

Because altcha-obfuscation is designed to allow de-obfuscation by capable clients (browsers or users), the fact that data can be recovered does not constitute a flaw or security vulnerability — it is intended and expected behavior. Marking this as a vulnerability is misleading and should be withdrawn.

Context — how ALTCHA’s obfuscation works

• ALTCHA’s “Obfuscating Data” mode is not intended as a strong cryptographic protection. Instead, it uses a proof-of-work (PoW) + symmetric AES encryption mechanism to hide (obfuscate) data (e.g., email addresses, phone numbers, download links) to make it harder for bots to scrape data from a website.
• The data is encrypted with an encryption key + initialization vector (IV) derived from a random number. The “widget” requires the client (browser) to iterate over a range of possible numbers to find the correct IV — that is the PoW part.
• The default range is from 0 to 10,000, which determines de-obfuscation (decryption) complexity.
• Importantly: The documentation explicitly says “the goal is not to provide a secure cryptographic algorithm but to use a proof-of-work mechanism that allows any capable device to decrypt the hidden data.”

In other words: obfuscation in ALTCHA is meant to discourage automated scraping / bots, not guarantee cryptographic secrecy or resistance to determined attackers. Being able to decrypt the obfuscated data (with enough compute/time) is considered acceptable by design.

Why this means the advisory is incorrect

Based on the above:

• If the advisory claims that ALTCHA’s obfuscation “vulnerability” allows disclosure of hidden data — that is expected behavior by design. ALTCHA does not promise irreversible encryption: de-obfuscation by client (or attacker) is accepted because the objective is just to block naive bots, not to defend against determined attackers.
• Therefore, labeling this behavior as a “security vulnerability” (e.g. a flaw that must be fixed) ignores ALTCHA’s stated design goals.
• The advisory likely treats “data obfuscation that can be reversed or bypassed” as a vulnerability — but according to ALTCHA’s docs, that is not a flaw but the intended operation.
• Unless there is an additional cryptographic flaw (e.g. AES misuse, IV reuse, PoW weakness) that breaks the intended threat model, the advisory is incorrect.

[eternal-flame-AD]

Hi, I am the reporter of the issue.

• You are free to dispute it, but you need to go through the proper channels, which in this case is the MITRE CNA. You are welcome to wait for an official response but I guarantee you this is what they will say as well .
• I engaged you constructively according to your posted timeline (more than 5 days) and communication channel, you did not respond for at least 2 weeks before I have to resort to doing a unilateral CVE entry. I don't believe it is considered good faith engagement to retroactively debate it when I gave you multiple opportunities to debate before I submit the entry.
• To answer your question : this is a crypt analytic break because there is no proof of work. You claim the feature required computational effort proportional to the "number" you set , and it is apparent from the referenced web material and your clarification that this computational effort is the primary if not sole way of achieving any practical deterrent to abuse.
• Simply saying "this is not cryptographic security", does not absolve the fact that the entire purpose of this feature is to provide at least some level of additional protection that is more than trivial encoding only methods like base64, and I believe this additional protection is proven to be invalid by this issue.

The PoC clearly demonstrate a constant time solution of trivial computational effort regardless of what difficulty parameter you use, not the "intended threat model". It is your freedom as the vendor to dispute it, but it doesn't change any facts about this disclosure.

[shelbyc]

Hi @ovx, @eternal-flame-AD is correct that submitting a dispute request to MITRE via https://cveform.mitre.org is an appropriate course of action. However, making a community contribution PR at the same time as submitting a community contribution is acceptable. In my guide "How to request a change to a CVE record," I listed a number of acceptable reference links to document public record of a dispute, including community contribution PRs.

I read https://github.com/eternal-flame-AD/altcha-deobfs and accept the validity of the PoC. I do think there's one action that would be appropriate: Adding exploit maturity to lower the CVSSv4 severity. Since there is no evidence of GHSA-mpmc-qchh-r9q8 being used in attacks, we could go from https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N to https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P. Let me know what you both think.

[eternal-flame-AD]

Hi, it looks like a great suggestion to me.

At this point I stand by my conclusion that this is a vulnerability and the time to debate scope has passed. However, I am open to text and CVSS metric modifications on the condition that the vendor provide input constructively through on the record channels and make evidence based proposals, instead of ignoring outreach and attempting to dispute with no factual basis without the reporter in the loop. I get it optics are important and an "unpatched" advisory looks scary, but against I can't reiterate enough how important it is to engage constructively and collaboratively.

[ovx]

Hi @shelbyc The original record has already been flagged as disputed: https://www.cve.org/CVERecord?id=CVE-2025-65849

I absolutely insist, that this not a vulnerability, it is intentionally designed to be this way. Please read the provided rationale and documentation.

[eternal-flame-AD]

it is intentionally designed to be this way

Designed in such a way that no matter how "difficult" you make it, there is a way to decode it instantly using 2 AES ops, while legitimate clients must submit to a long brute force loop?

[eternal-flame-AD]

Again look, I am not trying to cherry pick you or make you look bad, but :

• Plenty of time have been give for you to make an input or ask for clarification or ask for a timeline extension or ask for this to be handled like a bug not a vuln, you have multiple options I would have likely gladly accepted but you didn't. I won't be aware of this if not there was an unrelated enrichment issue of this entry and happened to find your after-the-fact dispute.
• You market this as a form of protection, I believe it is rational for your user to expect something more than basic encoding disguised as proof of work and a nontrivial percentage of your users would be believe this is a breach of security assumptions. The reality is this is no more secure than base64 against large volume data harvesting, you can argue this method is "sophisticated" all you want, but you should do it in the triage period, not retroactively after the entry is submitted because you refuse to provide an input or change the timeline.

[eternal-flame-AD]

Sorry your original post is very long. I had a chance to read it in completion. This is my response.

I mean if you just say "we use cryptographic tricks", nobody will unilaterally yell "vuln! this is a breach of security model", it's just an optimization trick.

Instead you say it's:

• "proof of work" (This is a specific term of art. This imply some tunable economic cost to do it at scale that is impossible to eliminate, when I proved there is a way, and it looks like the earlier staff and some of my personal connections both formed a second option agreeing this is a valid PoC indicating a categorical break not merely an optimization),
• "not for crypto-graphically secure (but claim to have made a PoW primitive out of AES)". With due respect this is what triggered me to check your code to begin with because it reads like we rolled our own crypto didn't bother getting it audited, we want the name of cryptography while now it looks like you are disclaiming any critical crypto design issues as "intended design/intended threat model"
• explicitly told users to make the operation "more expensive" via a lever (implying this makes abuse harder, instead what is does is make the legitimate experience worse and make the operator thought it is a good lever to deter abuse).

It's like "not financial advice" when blatantly saying "buy stock X because I work at an investment firm." When I point out the advice is dangerous and I plan to publish it you ignore me. When I do publish it you go behind my back and claim it's invalid because the label clearly said "NFA", not sure I follow your logic.

Again look, nothing personal. I tried to help you correct the issue via the channels you set up, you failed to make an input. I have no option except submit an entry to notify users that this feature provides a false sense of security. I am open to post hoc collaboration including modifying my part of the story to take your input into consideration, but it must be done transparently.

This is all I have to say on this issue. The CVE entry is published, the PoC is legitimate and confirmed by other people, and customers are notified of a legitimate issue and I have reviewed your latest input, therefore my duty as a reporter is finished. Whether you like to see the problem or not is not my concern.

[ovx]

My final statement; @shelbyc please conclude.

I confirm the technical finding that the specific construction of the AES-GCM PoW verification allows for an algebraic bypass, reducing the computational effort from a linear-time search (O(N)) to a constant-time calculation (O(1)). This is a cryptographic break of the mechanism’s performance assumption in the technical sense.

However, this analysis fundamentally misunderstands the security objective of the ALTCHA obfuscation feature, which is not cryptographic confidentiality, but imposing a high-cost integration barrier for mass automation.

The PoW feature is designed to filter out simple, general-purpose scrapers and mass botnets. It is achieved by forcing an attacker to commit resources to one of two expensive strategies:

• Browser Emulation: Expensive CPU/memory resources for running headless browsers (Puppeteer, Selenium, etc.).
• Non-Browser Automation: Deep developer expertise in low-level cryptography and complex library integration.

The constant-time algebraic solution, as demonstrated by the PoC, is not a viable shortcut for a simple bot. It is the mandatory minimum barrier for any automation attempt.

The algebraic bypass forces automators into a specific, high-effort development path:

• Required Specialization: To execute the O(1) solution, an attacker cannot use standard high-level libraries. They must implement a complex, low-level cryptographic inverse solution, including finite field arithmetic, for the GHASH component.
• High Integration Cost: This requires substantial, specialized development time to port the algebraic logic (like the one demonstrated in the Rust PoC) into a production bot environment. This is an extreme and unique hurdle not found in standard CAPTCHA or PoW solutions.
• Security Through Required Specialization: By making the PoC itself the mandatory entry ticket for non-browser automation, we ensure that only high-effort, custom-developed, and specialized bots can proceed. This is highly effective against the intended threat model of mass-market scrapers.

The mechanism's success is measured by the resources an attacker must commit to bypass it. The choice of AES-GCM was strategic because its native availability in browsers imposes zero overhead on legitimate users. Its low-level algebraic structure imposes a high integration cost on automated adversaries.

Conclusion

The Proof-of-Work (PoW) mechanism successfully transitions the attack cost from a computational burden (which the O(1) algebraic bypass invalidated) to a development and integration burden (which remains high). I conclude that for its intended non-confidential, deterrence-based purpose, the mechanism remains an effective and strategically strong filter against mass automation.

The author's findings conclude that the AES-GCM authentication mechanism is mathematically structured, allowing for non-iterative inversion of the input when other factors are known. This fact permits the Proof-of-Concept (PoC) to demonstrate trivial computational effort. However, this technical fact alone does not constitute an exploitable security flaw in the verification mechanism because:

1. The High Integration Cost imposed by the O(1) bypass serves as a secondary, highly effective protection vector against general-purpose bots.
2. No Confidentiality Harm: The PoC cannot be exploited to cause harm of any kind due to the public nature of the key and the non-confidential nature of the data.
3. Feasibility Constraint: Due to the strict constraints of the browser's native Web Crypto APIs, the fundamental structure of the AES-GCM PoW cannot be patched within the scope of this product.

Additionally, I recognize that a path exists to achieve a similar feature using a non-algebraic solution like PBKDF2 as the PoW mechanism, but this requires a complete rework of the feature. This is something that may be introduced later, after validating the feasibility and performance impact of such a change.

Since the report identifies a cryptographic limitation rather than a critical, actionable vulnerability, and because the consequence of the flaw is manageable through the Integration Cost barrier, I assert that the best practice is disclosure and risk acceptance.

I will implement the following documentation change to ensure full transparency for developers managing their risk appetite, and recommend the report be withdrawn as unactionable under the context of this product's threat model:

DISCLAIMER: Complexity and Automation
The computational complexity of the obfuscation Proof-of-Work (PoW) collapses to Constant Time O(1) when solved by custom non-browser automation tools. This is due to an algebraic bypass exploiting the GHASH component of AES-GCM.
* Browser Users: The intended Linear Time O(N) computational delay remains in place.
* Developers: Do not rely on this feature for genuine secrecy. The security is based solely on the high technical cost required for an attacker to implement the O(1) algebraic solution.

[shelbyc]

@ovx @eternal-flame-AD I discussed this thread with my team and we agreed to keep the advisory, albeit with a CVSS of CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P to reflect the lack of real-world exploitation.

We based this decision on the following documentation claim:

Decryption complexity depends on the number range used. By default, the range is 0 to 10,000 and can be adjusted using the script. The computation time is about 35% greater compared to the challenge PoW.

Since the documentation has a claim of taking O(n) time, the CVE is valid, albeit not as serious as CISA-ADP claims in their severity score.

Keeping the advisory but using a CVSS that reflects the limited impact and lack of real-world exploitation reflects the situation most accurately.

[ovx]

Hello @shelbyc , I understand your decision, but can you please suggest a possible fix for this issue so that we can deliver a patch? The author does not seem to provide one.