During routine monitoring of activity in the NPM registry, a suspicious pattern was discovered by Mend.io specialists involving the account sdjkals, which has released 10 packages that include files presented as WOFF2 font resources. A preliminary review indicates that these files are not genuine font assets.
Those packages are published within the @sdjkals/* scope, and their version numbers have climbed to 1.0.1594 and 1.0.1912, reflecting an unusually aggressive republishing cadence—new releases appear every few minutes. Each package contains 31–33 files named according to the segment_NNNNNN.woff2 convention; individual segments are 2–3MB, and the overall package size is approximately 90MB. In total, the observed set includes 284+ segment files.
Across all cases, the internal layout remains the same:
- a barebones package.json with a generic “Assets” description
- a minimal index.js that exports CSS references for fonts
- the segment files themselves
While the segment headers include valid WOFF2 magic bytes, font-parsing utilities still reject the files as malformed. Binary inspection suggests the underlying data may be encrypted or compressed using a non-standard scheme.
Payload segmentation analysis
The way segments are spread across the packages indicates intentional fragmentation:
@sdjkals/lib-v1-ifmt → segments 000128-000158
@sdjkals/media-static-pro → segments 000283-000313
@sdjkals/adapter-core-v1 → segments 000408-000438
@sdjkals/data-dist-387w → segments 000656-000686
@sdjkals/assets-loader-nse4 → segments 000717-000747
@sdjkals/data-lib-kernel → segments 000748-000779
@sdjkals/shim-theme-v2 → segments 000842-000873
@sdjkals/font-core-v1 → segments 001025-001056
@sdjkals/adapter-theme-kernel → segments 001059-001090Numbering gaps between segment ranges are evident from one package to another. This points to a split-payload design in which the full data set can only be reconstructed by installing multiple packages. The approach is frequently associated with attempts to evade automated detection workflows that evaluate packages individually rather than as a combined set.
The versioning behavior is also abnormal. @sdjkals/data-lib-kernel has already reached v1.0.1912, and other packages show similarly inflated version strings (v1.0.1594, v1.0.1614). Cycling versions at this pace can serve several goals: it hinders meaningful diff-based tracking, injects noise into registry-monitoring pipelines, and may constitute abuse of NPM’s storage and bandwidth infrastructure.
Threat assessment
This pattern introduces several security risks:
- Infrastructure Abuse: The actor appears to be using NPM’s CDN and storage as a hosting layer for nearly 900GB of obfuscated data distributed across multiple packages, while continuous republishing further increases resource usage.
- Split-Payload Distribution: The segmented layout is typical of multi-stage payload delivery mechanisms. By scattering segments across multiple packages and keeping the numbering non-sequential, static analysis becomes harder. This way the probability that automated systems will mark any single package as malicious is reduced.
- Detection Evasion: On the surface, each package looks harmless, containing only font-like files and a very small amount of JavaScript. No obvious execution hooks, suspicious outbound network activity, or overt code obfuscation is present. As a result, conventional heuristic checks may struggle to flag these packages.
- Signal Flooding: Rapid version increments generate substantial noise for security monitoring tools that track package updates, which can either conceal other malicious activity or contribute to alert fatigue.
Conclusion
The overall sophistication—split payloads, file-format impersonation, and high-speed iteration—aligns with either a proof-of-concept for supply-chain attack techniques or purposeful abuse of infrastructure for data storage and distribution.
