Skip to content

Mojic: Observable Timing Discrepancy in HMAC Verification

Moderate severity GitHub Reviewed Published Apr 15, 2026 in notamitgamer/mojic • Updated Apr 27, 2026

Package

npm mojic (npm)

Affected versions

<= 2.1.3

Patched versions

2.1.4

Description

Summary

The CipherEngine in Mojic v2.1.3 uses a standard equality operator (!==) to verify the HMAC-SHA256 integrity seal during the decryption phase. This creates an Observable Timing Discrepancy (CWE-208), allowing a potential attacker to bypass the file integrity check via a timing attack.

Details

In lib/CipherEngine.js, the footer check validates the HMAC signature using a standard string comparison:
if (footerHex !== calcDigest) { ... }

Standard string comparisons in JavaScript short-circuit; they return false the moment a character mismatch occurs. Because the time taken to evaluate the comparison is proportional to the number of matching leading bytes, an attacker can measure the exact microseconds it takes for the engine to throw the FILE_TAMPERED error. By repeatedly altering the signature byte-by-byte and analyzing these minute timing differences, a malicious actor can theoretically forge a valid HMAC signature without possessing the decryption password.

PoC

The vulnerable implementation is located in lib/CipherEngine.js, within the getDecryptStream() flush method (approximately line 265):

// Vulnerable Code
if (footerHex !== calcDigest) {
    this.emit('error', new Error("FILE_TAMPERED"));
    return;
}

Recommended Remediation:

Replace the standard equality operator with Node.js's built-in constant-time comparison utility, crypto.timingSafeEqual().

// Remediated Code
const footerBuffer = Buffer.from(footerHex, 'hex');
const calcBuffer = Buffer.from(calcDigest, 'hex');

if (footerBuffer.length !== calcBuffer.length || !crypto.timingSafeEqual(footerBuffer, calcBuffer)) {
    this.emit('error', new Error("FILE_TAMPERED"));
    return;
}

Impact

If successfully exploited, an attacker could tamper with the encrypted .mojic payload and forge a valid HMAC signature. This bypasses the integrity seal, tricking the decryption engine into processing maliciously injected emoji streams. Because the engine translates these emojis back into C keywords and raw data chunks, this could ultimately result in arbitrary Code Injection into the restored .c source code when an unsuspecting user decrypts the tampered file.

References

@notamitgamer notamitgamer published to notamitgamer/mojic Apr 15, 2026
Published to the GitHub Advisory Database Apr 16, 2026
Reviewed Apr 16, 2026
Published by the National Vulnerability Database Apr 24, 2026
Last updated Apr 27, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
High
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(2nd percentile)

Weaknesses

Observable Timing Discrepancy

Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not. Learn more on MITRE.

CVE ID

CVE-2026-41244

GHSA ID

GHSA-wqq3-wfmp-v85g

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.