AXB Sender Suite V2

AI Security Review

Evidence context: threat category none; evidence quality moderate.

AXB Sender Suite V2 ships from developer [email protected] with a Portuguese description calling it an automation, CRM, ERP and maturação system for AXB Digital. The manifest declares no permissions and no host permissions. The scan found zero IoCs, zero malware signatures, zero obfuscation, zero dependency findings and zero exposed secrets. Everything flagged sits in a single bucket: seven medium-severity network findings, each one recording a fetch call.

Those seven calls live at background.js:71, content.js:17, content.js:718, popup.js:56, modules/axb-agenda.js:254, and modules/axb-auth.js:83 and modules/axb-auth.js:130. The file names map onto the advertised feature set. An auth module issuing two requests handles sign-in and token refresh. A scheduling module issuing one handles calendar sync. A popup issuing one contacts a backend when the user opens it. A background service worker issuing one polls or syncs. This is the shape of a thin client for a hosted business service, not a hijacker.

Nothing ties any of those requests to an unknown destination. The scan extracted no endpoints at all, which means the URLs are built at runtime or read from configuration and the tooling could not follow them. That absence cuts both ways, and it is the strongest argument against a clean read: without destinations, we cannot confirm where customer data lands. A skeptic would say seven unexplained fetches, six users and a Gmail developer is the profile of a low-effort data collector. That reading needs an assumption the evidence does not support. No credential-harvesting patterns, no cookie access, no content scripts injected into login pages, and no domains surfaced anywhere in the bundle. If data were going somewhere hostile, the network extractor would normally have named the host.

The empty permissions and host_permissions arrays also cap what this code can do. Without them it cannot reach arbitrary pages, read cookies, or intercept requests without user action, and its fetches answer to the same CORS rules as any page script. The seven findings describe an API surface, not privileged behavior.

The finding titles themselves carry no more than the line they point at. NET-FETCH-modules/axb-auth.js-83 says a request happens at line 83 of an auth module. NET-FETCH-popup.js-56 says a request fires when the popup opens. Neither carries a domain, payload, or header. A scanner reports a request line the same way whether it reaches the vendor's own API or somewhere else.

What would change this read: a re-scan that resolves the fetch destinations, or runtime capture showing traffic to a host unrelated to AXB Digital's service. Until then, the network finding count is the expected output of scanning any extension that talks to a backend.

Key Reasons

• All seven findings are NET-FETCH entries recording call sites in the extension's own modules, with no destination domains extracted
• Manifest declares an empty permissions array and an empty host_permissions array, so the extension holds no privileged browser access
• Zero IoC, malware-signature, obfuscation, dependency, secret or code-smell findings anywhere in the bundle
• File names (axb-auth.js, axb-agenda.js, popup.js, background.js) match the automation and scheduling features described in the listing
• No credential-harvesting patterns, cookie access, or content scripts targeting login domains

False Positive Considerations

• Network findings record fetch call sites only and carry no endpoint, payload or header data
• Empty permissions and host_permissions arrays mean no privileged capability to weigh against the network findings
• No obfuscation, IoC or malware-signature findings to corroborate the network detections
• Install base of 6 users offers no behavioral telemetry to confirm or dismiss the calls

Reviewed 2026-10-13; recommended action: no action; model confidence 72%.