v3.0.2

What's changed

• fix: deps updated
• ci: reject AI attribution and vendor-locked agent config

The dependency bump restores safeNetworks exemptions

@imqueue/net moves to ^3.0.5, which carries a membership fix that could otherwise strip a trusted address of its exemption.

HttpProtect tests safeNetworks with Networks.includes(). In @imqueue/net before 3.0.4, that could answer false for an address a listed network genuinely covered, whenever the list held three or more entries and one was a subnet of another:

new HttpProtect({
    safeNetworks: ['192.168.0.0/16', '10.0.0.0/8', '10.1.0.0/16'],
});
// 10.9.9.9 was not treated as exempt, though 10.0.0.0/8 covers it

The failure was fail-closed and silent: an address that should have bypassed the counters was counted, rate-limited, and eventually banned, with nothing logged to explain why.

Ban lists were never affected. bannedNetworks() builds its set from /32 records only, which are always disjoint, so the bug could not reach it.

Upgrading

npm i @imqueue/http-protect@3.0.2. The declared range is now ^3.0.5, so a fresh install cannot resolve an affected version — but an existing lockfile can still hold one, so check that @imqueue/net resolves to 3.0.5 or later after upgrading.

Full Changelog: v3.0.1...v3.0.2

About

@imqueue/http-protect — HTTP DDoS protection middleware. Part of the @imqueue framework for Node.js & TypeScript microservices.

• Docs: https://imqueue.org/
• Guide for AI assistants / LLMs: https://imqueue.org/llms.txt
• Commercial license & support: https://imqueue.com/
• npm i @imqueue/http-protect