NPM User Flooding Registry with Fake Font Packages

Last Updated: December 16, 2025 – 1:02 PM ET

During routine monitoring of NPM registry activity, we identified a suspicious pattern involving user sdjkals who has published 10 packages containing what appear to be WOFF2 font files. Initial analysis reveals these are not legitimate font assets.

The packages are scoped under @sdjkals/* with version numbers reaching 1.0.1594 and 1.0.1912, indicating extremely rapid republishing cycles, new versions are being pushed every few minutes. Each package contains 31-33 files following the naming pattern segment_NNNNNN.woff2, with individual segment sizes of 2-3MB and total package size around 90MB. Across all observed packages, there are 284+ segment files.

Package structure is consistent across all instances: minimal package.json with generic “Assets” description, a trivial index.js exporting font CSS references, and the segment files themselves. The segments have valid WOFF2 magic bytes in their headers, but font parsing tools reject them as malformed. Binary analysis suggests the data may be encrypted or compressed using a non-standard format.

Payload segmentation analysis

The segment distribution across packages shows deliberate 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-001090

Notice the gaps in segment numbering between packages. This suggests a split-payload architecture where the complete data set requires assembly from multiple package installations. This technique is commonly used to evade automated detection systems that analyze individual packages in isolation.

The version numbers themselves are anomalous. @sdjkals/data-lib-kernel has reached v1.0.1912, with other packages similarly inflated (v1.0.1594, v1.0.1614). The rapid version cycling serves multiple purposes: it obscures meaningful change tracking, generates noise in registry monitoring systems, and potentially abuses NPM’s storage and bandwidth infrastructure.

Threat assessment

This pattern presents several security concerns:

Infrastructure Abuse: The actor is leveraging NPM’s CDN and storage to host nearly 900GB of obfuscated data across multiple packages, with continuous republishing amplifying the resource consumption.

Split-Payload Distribution: The segmented architecture is characteristic of multi-stage payload delivery systems. By distributing segments across packages with non-sequential numbering, the actor makes static analysis more difficult and reduces the likelihood of automated detection flagging any single package as malicious.

Detection Evasion: Individual packages appear benign, they contain only font files and minimal JavaScript. There are no obvious code execution hooks, no suspicious network requests, no obfuscated code. This makes them difficult to flag using conventional heuristics.

Signal Flooding: The rapid version bumping creates noise in security monitoring systems that track package updates, potentially masking other malicious activity or causing alert fatigue.

Conclusion

The sophistication of this operation, split payloads, mimicked file formats, rapid iteration, suggests either a proof-of-concept for supply chain attack methodologies or active infrastructure abuse for data storage/distribution.