Topic starter
19/08/2026 3:53 pm
TL;DR: A full phishing and bulk-mail framework was hidden inside obfuscated npm versions 1.0.299 through 1.0.307 of nolimit-agent, using Microsoft 365 device-code approval to read mail through Graph, impersonate senders, and beacon to api.nolimitent.xyz, according to Xygeni. Package distribution now carries a direct identity abuse path, not just a malware delivery risk.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “DeviceDoor: a public npm package shipping a Microsoft 365 device-code phishing and bulk-mail framework”.
Key questions
Q: What breaks when an npm package hides its real code behind a clean install hook?
A: The review model breaks because security teams often inspect lifecycle scripts more closely than resolved runtime entry points.
Q: Why do device-code approvals create risk in Microsoft 365 environments?
A: They let a user complete authentication on a separate device and hand a requester usable tokens without ever exposing a password.
Q: What are the signs that mailbox access is being used for phishing preparation?
A: Watch for successful device-code sign-ins followed quickly by Graph reads of inbox and sent items, especially when the session is unfamiliar or originates from a developer or build host.
Practitioner guidance
- Tighten device-code authentication policy Restrict Microsoft 365 device-code flow wherever interactive use is not required and log every successful approval for review against mailbox access that follows immediately after.
- Block hidden obfuscated runtime paths Treat packages whose main or bin resolves into dot-prefixed, obfuscated directories as high risk and require unpacked code review before promotion into developer or CI environments.
- Hunt for the operator beacon host Search proxy, DNS and endpoint logs for api.nolimitent.xyz on developer workstations and build agents, then quarantine systems that contacted the host while installing the package.
Bottom line: A malicious npm package can hide real capability behind an apparently routine install path and still execute a full phishing workflow after installation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:30 pm
Package distribution has become an identity-abuse channel, not just a code-delivery channel. This article shows a malicious registry package using a legitimate OAuth consent flow to reach mailbox data after installation. That collapses the old separation between software supply chain review and identity control, because the dangerous action happens after the package is already trusted enough to run. Practitioners should treat package intake as an authentication-risk decision, not only a software provenance decision.
A few things that frame the scale:
- Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.
A question worth separating out:
Q: Should teams prioritise package provenance or authentication controls first?
A: They need both, but package provenance comes first when the package itself can trigger identity abuse. In this case, the dependency was the delivery vehicle for a Microsoft 365 consent flow, so the safer order is to block suspicious packages at intake and then harden the authentication path they try to exploit.
👉 Read our full editorial: Npm package nolimit-agent turns device-code phishing into supply chain risk