lote.guide
esc
  • npm lifecycle scriptsscripts field in package.jsonNode.js
  • setup.py arbitrary code executionsetup.py in source distributions (sdist)Python
  • NODE_OPTIONS preload injectionNODE_OPTIONS environment variable, CLI flags, or .env files loaded via --env-fileNode.js
  • .pth file import execution*.pth files on sys.path (commonly site-packages)Python
  • binding.gyp / node-gyp native compilationbinding.gyp file in the package rootNode.js
  • Corepack (packageManager field)"packageManager" field in package.json, COREPACK_HOME cache directoryNode.js
  • .npmrc registry manipulation.npmrc file (project, user, or global)Node.js
  • overrides / resolutions dependency swapoverrides (npm) or resolutions (Yarn) field in package.jsonNode.js
  • pnpm hooks (pnpmfile.cjs).pnpmfile.cjs in the project rootNode.js
  • .yarnrc.yml plugins and registry.yarnrc.yml in the project rootNode.js
  • pyproject.toml build backendspyproject.toml [build-system] tablePython
  • sitecustomize / usercustomize auto-importsitecustomize.py / usercustomize.py on sys.path (usually site-packages)Python
  • .node native addon loading.node files in node_modules/ (typically under build/Release/ or prebuilds/)Node.js
  • Yarn Plug'n'Play (.pnp.cjs).pnp.cjs in the project rootNode.js
  • __init__.py execution on import__init__.py in any package directory on sys.pathPython
  • .pyc bytecode cache poisoning.pyc files in __pycache__/ directories alongside source modulesPython
  • PYTHONPATH / PYTHONHOME module shadowingPYTHONPATH / PYTHONHOME environment variablesPython
  • npx / npm exec remote executionnpx, npm exec, npm create / npm init (initializer flows)Node.js
  • conftest.py auto-loading (pytest)conftest.py files in any directory pytest traversesPython
  • NODE_PATH environment variableNODE_PATH environment variableNode.js
  • "imports" field (subpath imports)imports field in package.jsonNode.js
  • require.extensions / Module._extensionsrequire.extensions / Module._extensions in any loaded moduleNode.js
  • .egg files and EGG-INFO scripts.egg files in site-packages (registered via easy-install.pth)Python
  • Zip imports (zipimport).zip / .pyz files on sys.path, or passed directly to the interpreterPython
  • PYTHONSTARTUP environment variablePYTHONSTARTUP environment variablePython
  • node_modules/.hooks/ directorynode_modules/.hooks/ directoryNode.js
Node.js
Install time/File on disk

Corepack (packageManager field)

Transparently, when package manager commands are mediated through Corepack

Lives in
"packageManager" field in package.json, COREPACK_HOME cache directory
Attacker needs
Supply-chain foothold, Registry / config control
Lifecycle
Install
Startup
your code
Module load
Runtime
REPL

Runs while dependencies download and build. The app has never started.

How it runs

Corepack is a transparent proxy for package managers. It reads the "packageManager" field in package.json, then downloads and runs the specified version of yarn, pnpm, or npm.

{ "packageManager": "yarn@4.5.0" }

When Corepack is enabled, it sits between you and yarn install. It makes sure the pinned version is available, downloads it if needed, and executes it. The weak point is the field itself. Anyone who can modify package.json can point it at a malicious package-manager version. Corepack fetches from the npm registry by default, so a typosquatted name resolves the same way any other npm package does.

COREPACK_HOME controls the cache directory, and poisoning it backdoors every project on the machine. Custom-URL fetches via corepack prepare skip the known-good integrity list entirely. And because Corepack intercepts the package manager binary, a compromised version controls the entire install pipeline. That includes resolution, lifecycle scripts and lockfile generation.

Defend

Pin and review the packageManager field; protect COREPACK_HOME; avoid corepack prepare from custom URLs; prefer known-good official versions.