diggylab-worker@0.1.37
DiggyLab Desktop Agent collects posts and information from Facebook Groups on a paired computer. (self-hosted scan worker)
AI Security Review
scanned 6d ago · by lpm-firewall-aiThe login path transfers validated Facebook session cookies to the package-selected DiggyLab API. This is concrete credential disclosure to a recipient separate from Facebook, and the source does not establish recipient-specific consent before sending.
Static reason
One or more suspicious static signals were detected.
Trigger
A user runs the worker’s `login` command after registering and assigning an account.
Impact
The API recipient receives Facebook session credentials that can authenticate as the user.
Mechanism
The login flow packages the Facebook storage state and posts it to the worker API; the source shows no separate recipient-specific consent gate before that transfer.
Attack narrative
During the explicit Facebook login flow, the worker validates the session and then sends its storage state to the default DiggyLab API. The flow also saves a local copy, but the remote transfer exposes reusable Facebook credentials to a recipient separate from Facebook without a distinct consent step shown in the source.
AI rationale
The login path transfers validated Facebook session cookies to the package-selected DiggyLab API. This is concrete credential disclosure to a recipient separate from Facebook, and the source does not establish recipient-specific consent before sending.
Evidence
worker.js
Network endpoints1
api.diggylab.com
Decision evidence
public snapshotAI called this Malicious at 91.0% confidence as Malware with low false-positive risk.
Evidence for block
- The worker defaults its API destination to the package publisher’s DiggyLab service.
- The Facebook login flow validates the session, then passes the resulting storage state to `finishWorkerLogin`.
- `finishWorkerLogin` sends the storage state to the worker API and also saves a local copy.
- The API sends the storage state in a POST to `/worker-node/session`.
- The login path accepts a configured API origin, while the package default remains `https://api.diggylab.com`.
Evidence against
- The transfer occurs during the explicit `login` command, and the worker reports that the Facebook session was sent to the server.
Behavioral surface
ChildProcessCryptoEnvironmentVarsFilesystemNetwork
HighEntropyStringsUrlStrings
NoLicense
Source & flagged code
4 flagged · loading sourcepackage.jsonView file
•scripts.postinstall = node worker.js install-browser
High
Install Time Lifecycle Scripts
Package defines install-time lifecycle scripts.
package.jsonView on unpkg•scripts.postinstall = node worker.js install-browser
Medium
Ambiguous Install Lifecycle Script
Install-time lifecycle script is not statically allowlisted and needs review.
package.jsonView on unpkgworker.jsView file
1383var DEFAULT_ORIGIN = "https://api.diggylab.com";
var WORKER_USAGE = `D
High
Ai Review Evidence
The worker defaults its API destination to the package publisher’s DiggyLab service.
worker.jsView on unpkg · L1383Findings
3 High4 Medium5 Low
HighInstall Time Lifecycle Scriptspackage.json
HighAi Review Evidenceworker.js
HighAi Review Evidenceworker.js
MediumAmbiguous Install Lifecycle Scriptpackage.json
MediumNetwork
MediumEnvironment Vars
MediumStructural Risk Force Deep Review
LowScripts Present
LowFilesystem
LowHigh Entropy Strings
LowUrl Strings
LowNo License
Affected versions and remediation
This report applies to diggylab-worker@0.1.37.
See all versions of diggylab-worker for other recorded verdicts.
- Avoid installing diggylab-worker@0.1.37. Remove it from direct dependencies and check your lockfile for transitive copies.
- Choose an independently verified alternative or release. This report does not establish that other versions are safe.
- If this version ran, investigate the affected machine and build environment. Rotate credentials it could access and rebuild from a trusted environment.
Evidence last updated: .
Think this verdict is wrong? Dispute it on GitHub or read how reports are produced.