403 on npm publish for private package

[jhulford]

🏷️ Discussion Type

Question

Body

I'm working on a private fork of the unmaintained package libxmljs. My fork is namespaced as @${mycompany}/libxmljs.

I had originally set it up to publish via Github Actions OIDC and confirmed it was working - I published several beta versions of the package. A couple weeks ago the publishing pipeline stopped functioning with out any perceptible change to any - no Github settings were changed at the repo level or the org level and nothing was changed in the npm package settings. I spent some time trying to diagnose it - the OIDC token exchange worked fine, the permissioning was correct but I couldn't get it to not 403 on the publish step. It always errored with the following:

npm notice Publishing to https://registry.npmjs.org/ with tag beta and restricted access
npm error code E403
npm error 403 403 Forbidden - PUT https://registry.npmjs.org/@${mycompany}%2flibxmljs
npm error 403 In most cases, you or one of your dependencies are requesting a package version that is forbidden by your security policy, or on a server you do not have access to.

Nothing worked so I resolved to simply just do manual deploys for the time being. However, I'm now also getting the same 403 errors when trying to publish manually. I know my token is valid and hasn't expired yet - I used it to publish other internal packages regularly.

Already ruled out:
token permissions, both "Publishing access" settings, version string (4 unused versions tried), payload (a 49 kB binary-free tarball fails the same as the real 2.1 MB one), .npmrc differences, and ownership (maintainer list identical to the working package).

Two things that might narrow it:

• Auth and 2FA both succeed. A raw PUT returns 401 + www-authenticate: OTP, and it returns exactly the same for another org namespace package, which publishes fine. Passing a valid --otp moves libxmljs to 403. So it's authorization, not authentication — and the two packages look identical at the auth layer.
• npm never prompts for the OTP on this package. Every other package opens the browser. This one goes straight to 403.

Is there any way to see the real reason behind that 403 — the CLI discards the response body.

I have already tried contacting npm support but haven't heard anything for several days.

[Pusri27]

To think about this kind of silent 403 error on npm is that the registry authorization layer is hitting a specific restriction on the package record itself rather than failing your user account or 2FA credentials, you know? It is basically telling the CLI that while your identity checks out, this specific package identifier is blocked by a registry rule or an organization tier quota

First off, to actually see the unredacted error payload that the npm CLI hides, you can run npm publish verbose or npm publish loglevel silly, which will dump the full HTTP request and response headers along with whatever JSON body the registry returned, or you can send a raw curl v X PUT with your Bearer token and inspect the npm notice and error body directly

A really common catch with scoped packages that suddenly start throwing a 403 on restricted publishes is your npm organization private package billing status, like if a payment failed, a trial lapsed, or private package limits were reached, npm quietly blocks private publishes under that org while still allowing public packages and regular auth, so double checking your organization billing tab on npmjs is definitely worth a look

Also, since you are publishing a fork of libxmljs which contains native C++ bindings, npm automated malware scanning pipeline or security hold system might have flagged the package name or binary build artifacts, and when an automated security hold gets placed on a package name, only [npm Support](https://support.github.com/?tags=dotcom-footer) can lift the backend flag, so having your silly log output ready for when they follow up on your ticket will help them unblock it right away

[justin24er]

Hey, nice job narrowing this down already the OTP behavior difference is a great clue.

A few things worth trying:

See the actual error body (npm's CLI hides it):

curl -X PUT https://registry.npmjs.org/@${mycompany}%2flibxmljs \
  -H "Authorization: Bearer $NPM_TOKEN" \
  -H "Content-Type: application/json" \
  -d @package.json -v

That'll show you the real JSON response instead of npm's generic message.

My best guess given your symptoms (no OTP prompt at all, straight 403, everything else identical): npm likely has an internal security/similarity policy flagging the base name libxmljs itself ,possibly due to its history or a typosquat-style check and it's blocking publishes regardless of scope, not something wrong with your token or org.

Quick way to test that theory: try publishing under a different name, like @${mycompany}/libxmljs-fork. If that goes through fine, you've confirmed it's name-based, not account/permissions-based.

For support, since you've waited days already, reply on the same ticket (don't open a new one) and mention explicitly that you suspect a name/security-policy block, not an auth issue. That tends to get routed to the right team faster.

In the meantime, GitHub Packages is a solid fallback for scoped private packages if you need to unblock CI.

[felipalb]

That is an incredibly frustrating issue, especially with the silent failure of the OTP prompt and the radio silence from support.

Let's break down how to extract the raw error response, and then look at the registry's system design to understand exactly why that OTP prompt is being skipped.

How to See the Raw 403 Response

By default, the npm CLI swallows the HTTP response body on 4xx errors. To force the CLI to dump the raw HTTP transaction (including headers and the JSON response body from the registry), run the publish command with the silly log level:

npm publish --loglevel silly > publish-debug.log 2>&1

Open publish-debug.log and search for http fetch PUT 403. Immediately below that, you will see the raw JSON response body returned by registry.npmjs.org. It usually contains an "error" key with a more descriptive string (e.g., "error": "You cannot publish over the previously published versions" or "error": "Package flagged as suspicious").

Analyzing the Clues: Why the OTP Prompt is Missing

Your observation about the missing OTP prompt is the smoking gun here. It tells us exactly where in the npm registry's architecture this request is being rejected.

In the npm registry system design, the publication flow works like this:

1. The Initial PUT: The CLI sends a PUT request with your authentication token (but no OTP).
2. The 401 Challenge: If the token is valid but the account requires 2FA, the registry rejects the request with a 401 Unauthorized and includes a WWW-Authenticate: OTP header.
3. The Interception (CLI): The npm CLI catches this specific 401 + header combination, pauses the process, and opens the browser or prompts your terminal for the OTP.
4. The Second PUT: The CLI retries the exact same PUT request, this time appending the --otp value.

If the CLI goes straight to 403 and skips the browser prompt, it means the registry never issued the 401 OTP challenge.

The server evaluated your initial request and hit a hard, unconditional block before or independent of the 2FA layer.

The Most Likely Culprits

Given that this is a private fork of libxmljs, here is what is almost certainly happening on npm's backend:

1. Automated Security Flagging (Most Likely)
libxmljs has a history of severe security vulnerabilities (it relies on C++ bindings to libxml2, which is notoriously difficult to secure). npm employs automated malware and spam scanners that analyze tarballs upon publication.
Because your package shares a name, and likely similar binary bindings and AST signatures with a known vulnerable package, npm's automated defenses have likely shadow-banned the package namespace or flagged it for manual security review. When a package is flagged this way, the registry responds with an immediate 403 to prevent malware proliferation, bypassing normal auth flows.

2. Typosquatting / Name Squatting Protections
Even within a private scope (@mycompany/), npm's backend has strict checks against packages that closely mirror high-traffic public packages to prevent supply-chain attacks. The sudden change in behavior suggests a recent update to npm's internal security heuristics caught your fork.

3. Spam Filter False Positive
Sometimes, pushing several beta versions in rapid succession (which you mentioned doing) triggers rate-limiting or spam heuristics, temporarily locking the package from further mutations.

Next Steps

1. Check the silly logs: Run the command above. The raw JSON body will confirm if it's a security flag (e.g., "code": "E403", "message": "Package flagged by automated systems").
2. The "Wait for Support" reality: If it is a security flag, you are entirely at the mercy of npm (GitHub) support releasing the hold. There is no CLI flag to bypass a server-side quarantine.
3. Temporary Workaround: If you are completely blocked on your pipeline, you might need to temporarily change the package name in package.json (e.g., to @mycompany/libxmljs-internal or @mycompany/xml-parser-fork). If this publishes successfully, it 100% confirms that the specific string @mycompany/libxmljs is sitting on an internal blocklist.

[jhulford]

Thank you all for the suggestions - unfortunately none of them really bore much fruit.

What I've currently landed on is that the 403 was the result of a security scan done on the contents of my README file. It currently contains demonstration code of an attack surface the port mitigates, patterns for avoiding xpath DOS'es and mentions of multiple CVE's that have been mitigated by the port. I think one or all of these tripped some content block.

I come to that conclusion because trying to publish the package under an entirely new company namespaced nonsense name without any binaries and only 3 files (one being the forks's full README) also 403'ed and publishing a different namespaced single file repo with a nearly blank README worked without issue.

[jhulford]

Confirmed. The prose in the README was the issue.

The text I had to remove was just an XML entity declaration with a file path as the entity content.