GHSA-966w-4vpf-p7hc: 
JavaScript analisi e mitigazione delle vulnerabilità

Impact

Versions of the aloma CLI (@aloma.io/aloma) up to and including 0.1.0 have several weaknesses in how they store and send the user's Aloma session and how they write pulled files.

1. Session sent to a host chosen by the current directory (High). The CLI read its configuration and its session from ./node_modules/@aloma.io/aloma in the current directory when that folder existed. A repository that ships such a folder with a .config/config.json could point the API URL at any host, and running any aloma command inside that checkout sent the stored session to it. (CWE-427)
2. Session file readable by other users (Medium; High on shared machines). The session was stored as plain JSON inside the installed package folder with default permissions (0644 file, 0755 folder). (CWE-732)
3. step pull / library pull could write outside the target folder, and names could inject code into file headers (High). Step and library names come from the workspace; names containing .. were written outside the target folder, and names or ids containing */ and line breaks could place code at the top of the written file. (CWE-22, CWE-94)
4. Dependencies with published advisories locked (High). axios 1.9.0, form-data 4.0.2, js-yaml 4.1.0, follow-redirects 1.15.9, diff 8.0.2, http-cache-semantics 4.1.1. (CWE-1395)
5. Credentials could follow redirects; http API URLs accepted (Medium). The sign-in exchange re-posted the ID token to the target of a 307/308 redirect, API calls forwarded the session on a redirect to another port of the same host, and http:// API URLs were used. (CWE-319, CWE-200)
6. Sign-in callback listened on all interfaces (Low). During the five-minute sign-in window the local callback server was reachable from the network. State and PKCE still protected the exchange. (CWE-1327)
7. secret list printed secret values (Low). Non-encrypted secret values were printed to the terminal and logs. (CWE-532)
8. Install-time script (Low, informational). A postinstall script ran the CLI on every install.

Patches

Fixed in 0.2.0:

• Configuration and session are read only from a per-user folder ($XDG_CONFIG_HOME/aloma, %APPDATA%\aloma on Windows, otherwise ~/.config/aloma), never from the current directory. A session kept by an older version inside the running package's own folder is moved there on first use and the old copy is removed. Nothing is imported from the current directory.
• The session file is owner-only (0600 in a 0700 folder); existing files are tightened.
• Pull keeps every file inside the target folder and skips unsafe names; header lines cannot close the comment.
• Dependencies updated and re-locked; CI and the publish workflow fail on npm audit findings.
• Calls that carry the ID token or session never follow redirects and require https (plain http only for a loopback host with ALOMA_ALLOW_HTTP_LOOPBACK=1).
• The sign-in callback listens on 127.0.0.1 and ::1 only.
• secret list masks values unless --reveal is given.
• No install-time scripts (the unused keytar dependency, which had its own install script, is removed).

Workarounds

Until you can upgrade:

• Run aloma only from directories you trust; never inside a cloned repository that contains node_modules/@aloma.io/aloma you did not install yourself.
• On shared machines, chmod 600 the .cache/session.json inside the installed package and run aloma logout when done.
• Pull steps and libraries only into a new, empty folder and review what was written.
• Do not use aloma secret list where output is logged.

What users should do

Upgrade: npm install -g @aloma.io/aloma@latest (and update any project-local installs). Then run aloma auth once if the CLI says you are not signed in. If you ran an older version inside a repository you did not write, or on a shared machine, sign in again and tell ALOMA support so the old session can be revoked. Remove any node_modules/@aloma.io/aloma/.cache folders left in project checkouts.