GHSA-7fqq-q52p-2jjg

What it actually does

OpenCC versions before 1.2.0 for the npm and PyPI packages can perform an out-of-bounds memory read when parsing truncated UTF-8 input. A caller that passes malformed or incomplete UTF-8 data into OpenCC conversion routines may cause the library to read past the intended input buffer. The most likely technical outcome is process instability or a crash, though out-of-bounds reads can sometimes expose adjacent memory contents depending on how the affected application handles errors, logging, and responses.

Why it matters to the business

Applications that use OpenCC to process user-supplied or externally sourced text may be vulnerable to denial of service if an attacker can repeatedly submit malformed UTF-8 content that crashes worker processes or conversion jobs. For services that rely on OpenCC in request handling, document ingestion, search indexing, localization, or text transformation pipelines, exploitation could cause outages, failed processing, degraded availability, and operational noise. There is no current KEV listing and no known mature public exploitation reported in the provided data, but the issue should still be remediated because malformed text input is common in internet-facing and data-ingestion workflows.

How an attack unfolds

An attacker identifies an application, API, batch processor, or content-ingestion path that uses OpenCC to convert text. The attacker then submits input containing truncated UTF-8 sequences, such as a multibyte character missing one or more continuation bytes. When the vulnerable OpenCC version processes that input, it may read beyond the end of the buffer. In a typical exploitation scenario, this causes the hosting process to crash or the conversion task to fail, enabling denial of service if the attacker can repeat the request or feed many malformed records. If the affected application logs memory-adjacent data, returns detailed conversion errors, or runs with unsafe memory diagnostics enabled, there may also be a limited risk of unintended information exposure, but availability impact is the primary concern.

How to fix it

Upgrade all affected OpenCC package instances to version 1.2.0 or later. For npm deployments, update opencc to 1.2.0 or later and rebuild/redeploy dependent applications. For PyPI deployments, update opencc to 1.2.0 or later in all Python environments, including application containers, virtual environments, build images, worker nodes, and serverless packages. Remove stale lockfile pins that force vulnerable versions, regenerate dependency lockfiles, and verify that transitive or vendored copies are also updated. As defense in depth, validate or normalize external text before conversion, reject malformed UTF-8 at trust boundaries, limit request/body sizes, isolate conversion workers, and ensure supervisors restart crashed workers without causing cascading service failure.

How to confirm the fix worked

Confirm package versions with dependency tooling such as npm ls opencc, npm audit, pip show opencc, pip freeze, pip-audit, safety, or software composition analysis. Validate that deployed artifacts, containers, and runtime environments contain OpenCC 1.2.0 or later, not only source repositories. Review lockfiles such as package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, requirements.txt, poetry.lock, Pipfile.lock, and container image manifests for vulnerable OpenCC versions. Where safe and authorized, run regression tests using malformed/truncated UTF-8 input against non-production instances to confirm the application rejects or handles the input without crashing. Monitor post-upgrade error rates and process restarts to ensure the fix is active in production-like environments.

Typical attack path

1. Locate an application feature, API endpoint, file upload path, message queue consumer, or batch job that performs Chinese text conversion using OpenCC.
2. Submit text containing malformed or truncated UTF-8 byte sequences.
3. Trigger OpenCC parsing or conversion of the malformed input.
4. Cause an out-of-bounds read in the vulnerable library.
5. Observe process crashes, failed conversion jobs, worker restarts, elevated error rates, or service unavailability.
6. Repeat the malformed submissions to sustain denial of service against the affected component.

How to detect it

To determine whether exploitation may already have occurred, review application, API gateway, web server, worker, container runtime, and process supervisor logs for crashes or restarts correlated with requests, uploads, messages, or records containing malformed UTF-8. Look for sudden increases in 5xx responses, conversion failures, segmentation faults, container restarts, core dumps, or worker deaths in components that use OpenCC. Inspect request samples, message payloads, uploaded documents, and ingestion records around crash times for invalid UTF-8 byte sequences, especially truncated multibyte sequences near the end of fields or files. In Linux environments, review syslog, journald, kernel logs, container logs, and crash dump infrastructure for segfault entries involving OpenCC-linked processes. In instrumented builds or test environments, AddressSanitizer, UBSan, or crash-reporting output that references OpenCC conversion paths and malformed UTF-8 should be treated as strong evidence of attempted triggering. Because no public exploit maturity or named threat actor activity is provided, detection should focus on behavioral evidence of malformed-input-triggered crashes rather than fixed network signatures.

• Segmentation fault
• segfault
• core dumped
• AddressSanitizer
• heap-buffer-overflow
• global-buffer-overflow
• out-of-bounds read
• invalid UTF-8
• malformed UTF-8
• truncated UTF-8
• opencc

What your security team should do

• Inventory all applications, services, containers, and build pipelines that include the npm or PyPI opencc package.
• Prioritize internet-facing services, file upload handlers, document ingestion systems, message consumers, and APIs that process untrusted text.
• Upgrade opencc to version 1.2.0 or later across npm and PyPI ecosystems.
• Regenerate and review dependency lockfiles to ensure vulnerable versions are not retained.
• Add malformed UTF-8 test cases to application security and reliability test suites for components that call OpenCC.
• Implement input validation that rejects malformed UTF-8 before invoking text conversion libraries.
• Monitor for crashes, abnormal worker restarts, and spikes in conversion errors that may indicate attempted denial-of-service activity.
• If crashes are observed, preserve logs, core dumps where policy allows, request samples, and surrounding telemetry for forensic review.