The npm-distributed build of claude-sesh 1.1.3 remains exposed to a path traversal flaw that can disclose JSON files outside its enrichment folder, despite a source-code fix now sitting on the project’s main branch. The important distinction is deployment: the GitHub fix was committed after the vulnerability report, but the package version is still 1.1.3 and its published compiled dist/services/enricher.js still constructs file paths from an untrusted session ID.

For Windows developers using

npx claude-sesh web

,

npm install -g claude-sesh

, or an MCP configuration that launches the npm package, a source commit is not a patch. Remove or disable the service until its installed runtime has been rebuilt from the fixed commit or the maintainer publishes a new npm release containing the fix.

The underlying report was filed as GitHub issue #2 on April 27, 2026, and SecNews subsequently reported it as a serious local file-read and file-write vulnerability. The repository maintainer closed the issue with commit

786c9d7

, titled “reject path-traversal session IDs in enricher.” That commit fixes the source. It does not, as of August 9, publish a new versioned package for the users who installed

claude-sesh

through npm.

Security dashboard illustrating a Claude-sesh path traversal vulnerability, outdated dependency, and exposed MCP endpoint.The vulnerable code is still what npm users run​

claude-sesh

is a local session explorer for Claude Code. It reads conversation history, exposes a dashboard, offers session search and statistics, and can run as an MCP server so an assistant can query prior work. It stores AI-generated enrichment data as JSON under

.claude-sesh\enriched

.

In the vulnerable 1.1.3 distribution,

src/services/enricher.ts

— and the compiled JavaScript shipped in

dist/services/enricher.js

— builds a storage path by directly joining the session identifier to the enrichment directory. Node’s

path.join()

normalizes traversal components such as

..

; it does not establish that the finished path is still inside the directory the developer intended.

That creates the familiar path traversal condition: a caller-controlled value can alter where a file operation lands. The vulnerable helper is used for reading enrichment data and for writing a newly generated enrichment record.

The issue report identifies

getEnrichedData(sessionId)

and

enrichSession(sessionId)

as affected, and GitHub’s pre-fix code supports the first half of that finding directly. A request to the dashboard’s enrichment endpoint supplies

sessionId

from the URL, and the server passes it straight to

getEnrichedData

without an allowlist or a final containment check.

The dashboard is not protected by an authentication layer in the affected source. Its endpoint for retrieving enriched data accepts a session identifier in the request path, calls the vulnerable reader, and returns the parsed JSON response. An attacker would still be limited to targets that resolve to a file ending in

.json

and whose contents can be parsed as JSON. That is a meaningful constraint, but it does not make session histories, tool configuration, application settings, JSON secrets, service-account material, or developer-created configuration files harmless.

The “local-only” framing misses the web server’s bind behavior​

SecNews characterizes the issue as requiring local access, and that description is fair for a strictly local MCP stdio setup: a process that can already send arbitrary calls to a user’s MCP server is already in a privileged position. But

claude-sesh

also offers a web dashboard, and its actual listener behavior deserves more attention.

The README says

npx claude-sesh web

opens a dashboard on

localhost:3847

. The server implementation calls Express

app.listen(port)

without specifying a hostname. Under Node.js behavior, omitting the host binds to the unspecified IPv6 address when available, or

0.0.0.0

otherwise — commonly exposing the listener on all network interfaces rather than only loopback.

That means the dashboard may be reachable from the local network if Windows Defender Firewall allows the Node process or the port has otherwise been opened. The project’s console message and documentation present the service as a localhost dashboard; the code does not explicitly enforce that boundary.

On a shared office network, a developer laptop connected to a permissive profile, a lab VM, or a development workstation with a broad inbound Node rule, the attack precondition changes. A nearby network client could reach an unauthenticated HTTP endpoint instead of needing a malicious local process or a compromised MCP client. There is no evidence that every Windows installation will be exposed this way — firewall policy decides that — but the service should be treated as network-facing until

netstat

, PowerShell, or a firewall rule confirms otherwise.

Read access is established; arbitrary write needs a narrower claim​

The public GitHub issue calls this an arbitrary file read/write vulnerability. The file-read path is straightforward in the web server: its

GET /api/enrich/:sessionId

route invokes

getEnrichedData

directly with the attacker-provided value.

The write claim is more complicated than the initial report suggests. The dashboard’s POST enrichment route does pass its user-controlled

sessionId

to

enrichSession

, and the pre-fix function eventually writes through the same unsafe path construction. But before it writes, it looks up an existing Claude Code session using that session ID and aborts when no session exists.

In other words, the repository contains a traversal-capable write sink, but the public source does not by itself demonstrate that an arbitrary traversal string can pass the preceding session lookup and reach the write. The GitHub reporter says they had a local reproduction and intended to add output and a screenshot, yet the visible issue contains no follow-up proof. No independent outlet located during this review has published a full reproduction or clarified the conditions needed for a write.

Administrators should not dismiss the write risk. The correct operational response is still to patch or remove the vulnerable package. But “unrestricted file overwrite” should not be repeated as independently established fact until a reproducible path through the session-validation step is published.

The main-branch fix is sound, but it has not been released​

Commit

786c9d7

replaces direct path construction with an

enrichedPathFor()

helper. It uses two controls:

  • It allowlists only letters, digits, underscores, and hyphens in session IDs.
  • It resolves the completed filename and verifies that its parent directory is exactly the intended enrichment directory.

That combination is the right repair pattern. Rejecting a literal

../

string alone is not enough, particularly on Windows, where both slash types are path separators and drive-qualified or UNC-style forms complicate simplistic filtering. A fixed identifier format prevents path syntax from entering the filename; checking the resolved result makes the filesystem boundary explicit.

The problem is distribution. The project’s current

package.json

still declares version 1.1.3. The npm package listed as the latest release is also 1.1.3, and its published compiled

enricher.js

is the old implementation without the allowlist or path containment logic. A user who simply reruns

npm install -g claude-sesh

, or invokes

npx claude-sesh

, can therefore receive the vulnerable program again.

Cloning

main

is not automatically sufficient either. The repository’s package entry points target

dist

files, while the security commit changes the TypeScript source. A local clone must be rebuilt successfully, and the active MCP or dashboard command must point to that rebuilt checkout rather than an older global npm installation.

What Windows administrators should do now​

Start by identifying how

claude-sesh

is launched. Look at Claude Code MCP configuration, user-level npm global packages, project dependencies, automation scripts, and any

npx claude-sesh

invocations. If the command resolves to npm’s 1.1.3 package, it is not protected by the main-branch source change.

Disable the MCP server and stop the web dashboard while validating the installation. For a controlled internal rebuild, use the repository revision containing commit

786c9d7

, install dependencies from the reviewed lockfile, run the project build, and verify that the active compiled

dist/services/enricher.js

includes both the session-ID allowlist and resolved-path containment check. Do not infer safety from the displayed version number: both the vulnerable package and the fixed source currently identify themselves as 1.1.3.

Also verify the dashboard’s listener. On Windows, check whether the Node process is listening on

127.0.0.1

or

::1

only, rather than

0.0.0.0

or

::

. Until the project explicitly binds the dashboard to loopback and offers authentication for any intentional remote use, firewall rules should block inbound access to port 3847 and any alternate port selected with

sesh web --port

.

Finally, review the enrichment directory and adjacent locations for unexpected JSON files or altered timestamps, using the same Windows account that ran the tool. Avoid opening untrusted files with applications that execute embedded content or scripts. The publicly documented flaw is primarily a confidentiality issue, but session-management tools routinely collect project names, file paths, prompts, summaries, and operational decisions that organizations would not intentionally expose to another machine on the network.

The CVE reference is not yet a reliable patch guide​

SecNews associates the report with CVE-2026-19327 and assigns a CVSS score of 5.3. That identifier does not appear in the GitHub issue or the fixing commit, which instead identifies the affected package as 1.1.3. The project’s MCP server source also reports its own protocol version as 1.0.0, likely explaining how version ambiguity entered the reporting.

As of August 9, the primary project record offers no released fixed version, advisory, CVE reference, changelog entry, or package publication that maps a safe npm artifact to the fix. The dependable indicator is the code itself: the active runtime must reject nonconforming session IDs and verify the resolved target remains inside the enrichment directory.

Until a rebuilt and newly versioned package appears,

claude-sesh

users should regard npm version 1.1.3 as vulnerable — and regard “fixed on main” as a maintenance note, not an installable remediation.

References​

  1. Primary source: secnews.gr
    Published: August 9, 2026 at 4:42 AM UTC

    Loading…

    www.secnews.gr
  2. Related coverage: app.unpkg.com

    Loading…

    app.unpkg.com
  3. Related coverage: classic.yarnpkg.com

    Loading…

    classic.yarnpkg.com
  4. Related coverage: claude.com

    Loading…

    claude.com
  5. Related coverage: app.unpkg.com

    Loading…

    app.unpkg.com
  6. Related coverage: marketplace.visualstudio.com

    Loading…

    marketplace.visualstudio.com
  7. Related coverage: curseforge.com

    Loading…

    www.curseforge.com
  8. Related coverage: claudepluginhub.com

    Loading…

    www.claudepluginhub.com
  9. Related coverage: community.f5.com

    Loading…

    community.f5.com
  10. Related coverage: jspm-packages.deno.dev

    Loading…

    jspm-packages.deno.dev
  11. Related coverage: pkg.go.dev

    Loading…

    pkg.go.dev
  12. Related coverage: npmjs.com

    Loading…

    www.npmjs.com
  13. Related coverage: nodejs.org

    Loading…

    nodejs.org
  14. Related coverage: nodejs.org

    Loading…

    nodejs.org
 

Click to expand...
You must log in or register to reply here.