You Could Edit Your Session. That Did Not Mean You Could Rewrite Everyone's Agent.

Omnigent got the permission check right. PUT /sessions/{session_id}/agent asked exactly the question a session scoped edit endpoint should ask: does this caller hold LEVEL_EDIT on the session named in the URL. For a session running its own, exclusive agent configuration, that check was the whole authorization decision, and it was correct. The gap sits one layer beneath it, in a question the endpoint never asked at all: is the agent this edit is actually about to overwrite exclusively this session's, or is it an object other sessions depend on too. That second question is where CVE-2026-62674 lives, and it is worth reading closely, because the first, correctly answered question is exactly what makes the second, unasked one easy to miss.

What a shared or template agent is inside Omnigent

Omnigent runs as a server and runner architecture in front of several coding agent backends, and its own release history, including the update that shipped the fix for this vulnerability, documents seven native harness integrations alongside a promoted software development kit tier, session forking with history, and an in app interface for creating and managing agents directly. An agent in Omnigent's data model is not only the per session configuration a user builds for their own work. Some agents are shared or built in objects, identified by an agent.session_id field set to none rather than bound to the one session that created them, meant to be reused as a starting configuration across many sessions rather than authored fresh each time. That distinction, a session exclusive agent versus a shared or template one carrying no single owning session, is exactly the distinction Omnigent's own direct MCP server editing endpoint already enforced before this vulnerability was patched, rejecting an edit to a shared agent with the stated guard that built in agents are read only through that endpoint.

The gap: a second endpoint that checked the container but not the object inside it

The full agent bundle upload path is a different, broader endpoint than the direct MCP edit path: rather than editing one field of an existing configuration, it accepts an entire replacement agent bundle and installs it in place of whatever the session currently pointed to. Building that endpoint's authorization check by copying the session level permission check alone, LEVEL_EDIT on the named session, without also copying the second, object level check the narrower MCP edit endpoint already had, is a specific and identifiable omission, not a general absence of access control. The advisory, the pull request and the fix commit each describe the correction the same way: an explicit guard, checked before any part of the uploaded bundle is processed, that rejects the request outright when the agent bound to the session is a shared or template agent rather than a session exclusive one. Omnigent's own maintainers describe the fix as positioned in the authorization chain ahead of any data mutation, which is the only place a check like this actually functions as a check: after the bundle has already overwritten the shared object, there is nothing left to reject.

Put plainly, two authorization decisions were collapsed into one where they needed to stay separate. Deciding whether this caller may edit this session is one decision, and the endpoint answered it correctly. Deciding whether the specific agent object the edit resolves to belongs exclusively to that session, or is instead a shared resource other sessions and other users already depend on, is a second, separate decision, and nothing on this path made it. A caller who never asked to touch anyone else's session did not need to. The session they were genuinely authorized to edit simply happened to point at something bigger than itself, and the endpoint treated authority over the pointer as authority over what it pointed to.

What a malicious stdio MCP server buys once it is inside the shared bundle

A replacement agent bundle is not limited to prompt text or model configuration. It can declare tool servers the agent connects to, including a stdio transport Model Context Protocol server, which Omnigent's own runner starts as a subprocess on the runner host itself whenever a session loads an agent configured to use it. That is the mechanism that turns an authorization gap into remote code execution: a bundle carrying a stdio MCP server pointed at an attacker chosen command does not need the runner to fetch anything external or evaluate anything unusual, it only needs a later session to load the now poisoned shared agent the way it was always meant to, and the runner does exactly what a legitimately configured tool server would have done, launch the configured command as its own subprocess, with whatever privileges the runner process itself carries on the host machine.

The consequential property here is not the mechanism of code execution on its own. A stdio tool server that runs a configured command is working as designed; Model Context Protocol did not fail here any more than it failed in this desk's own earlier examination of an unrelated authorization gap where an ordinary MCP transport carried a conforming, unremarkable request into a completely different failure. What makes this vulnerability distinct is that the actor who plants the command and the sessions that later run it are not the same actor, and do not need to overlap in time at all. Whoever exploited this endpoint needed only ordinary edit permission on one session, exercised once. Every future session that loads the poisoned shared agent, run by any user with legitimate reason to use that agent, executes the planted command without making any decision of their own that a reviewer could have caught.

The fix, and what it does not retroactively undo

Omnigent 0.3.0 adds the missing guard: the bundle upload endpoint now rejects a request when the target agent's session_id is none, the same signal the MCP edit endpoint already used to identify a shared or built in agent, before any part of the uploaded bundle is accepted or applied. That closes the path this record describes. It does not, on anything this record's search could establish, describe a mechanism for detecting or reversing a shared agent that was already overwritten before an operator upgraded to the patched version. Whether Omnigent's own project material documents a way to inspect a shared agent's bundle history, or to confirm a given shared agent was never modified through this path before the fix, is not established by the advisory, the pull request or the release notes this record could retrieve. This record states that as an open question rather than assuming either that recovery guidance exists or that it does not.

Chronology: the fix predates the disclosure, and Moona's own coverage predates neither

The pull request that carries the fix merged on 26 June 2026. Omnigent 0.3.0, the release that shipped it, went out the following day, 27 June 2026. The GitHub Security Advisory and CVE-2026-62674 were published two days after that, on 29 June 2026, an ordinary and unremarkable order for a project disclosed vulnerability: fix first, then a release carrying it, then the public advisory describing what the release quietly fixed. Moona Intelligence's own coverage sits a further two months beyond all three dates, surfaced through this desk's own systematic sweep for qualifying agent authority evidence rather than through any new event on Omnigent's side. This is not a 3 September 2026 vulnerability. It is a vulnerability fixed in June and disclosed in June, reaching this record as a late discovered signal in September, and the distance between those dates changes nothing about the mechanism, only about when this desk is able to state it.

Operation authority is not target authority, with a shape this desk had not yet recorded: persistence to a future, uninvolved actor

A patched AshAi vulnerability showed the same abstract shape in a single request: a caller authorized to update the one record their own identity argument named instead reached a different record entirely, because the argument meant to bind the operation to a target could itself be reinterpreted as a broader selection. That gap resolved and completed inside one request, one caller, one authorized operation reaching further than it should have, and nothing about it outlived the request that triggered it. This vulnerability shares the same authority gap, an operation correctly authorized at one level silently equated with authority over whatever the operation actually resolves against, but adds a property AshAi's case did not have. The caller who exploits it does not need to be the one who suffers the consequence, or even present when the consequence lands. A session edit permission, exercised once, mutates a shared object that persists after the exercising session ends, and every later session that legitimately loads that shared agent inherits whatever was planted in it, with no further decision by the attacker required and no further authorization check standing between the poisoned configuration and the runner that executes it.

This desk has already argued that delegation quietly doubles as an authority transfer, when one agent spawns or forks another and the child inherits the parent's authority without narrowing it. That pattern and this one share a family resemblance, unattenuated authority reaching further than the actor who granted it intended, but they are not the same mechanism and this record does not fold one into the other. Delegation inheritance happens between two agents in an active hierarchy, a parent and the child it deliberately spawned. This vulnerability has no delegation step and no hierarchy: the sessions that later load a poisoned shared agent are not descendants of the session that poisoned it, are not aware it happened, and would ordinarily have no relationship to the exploiting session at all beyond both having once pointed at the same shared object.

Separately, research this desk has covered as a still experimental candidate weakness describes an instruction embedded in a persistent file propagating from one agent to the next when that file is read into a later agent's own context. That mechanism and this vulnerability both produce the same outward shape, a change one actor introduces reaching a different, later actor through persistent state rather than through any direct interaction between them, and both belong to a broader pattern this desk is now confident is real: persistent, shared configuration can carry authority forward to actors who never consented to inherit it. But this record keeps them distinct rather than treating one CVE as proof of the other's mechanism. The research case describes content an agent voluntarily reads and can, in principle, choose to weigh or discard. This vulnerability describes a platform level authorization check that failed to distinguish an owned resource from a shared one, with no voluntary reading step and no judgment call available to the sessions that inherited the planted command; they ran it because loading a configured tool server is exactly what a session using that agent is supposed to do.

Omnigent's Authority Provenance ledger

Moona Intelligence applies the same set of questions to this vulnerability that this desk applies to every mechanism it examines, reading the project's own advisory, pull request and commit rather than a secondary account.

Authority grantor. Omnigent's own session authorization mechanism, whatever internally assigns and checks LEVEL_EDIT permission on a named session. Nothing this record could verify documents who or what decides that a given user should hold that permission on a given session in the first place; this record states that as unestablished rather than assuming a specific access model.

Mandate or basis. LEVEL_EDIT permission on one identified session, a narrow, ordinary and, on its own terms, correctly enforced grant. The vulnerable endpoint never asked a second, separate question this record's own reading treats as a distinct mandate: whether that grant extended to the shared or template agent the session happened to reference, rather than only to the session itself.

Delegated scope. Intended scope was the caller's own session and whatever agent configuration was exclusively bound to it. Actual scope, on the vulnerable path, reached any shared or template agent any session the caller could edit happened to point to, an object other sessions and other users also depended on and had no part in exposing.

Explicit limits. A limit existed elsewhere in the same system: the direct MCP server edit endpoint already rejected a shared agent with the stated guard that built in agents are read only through that endpoint. The bundle upload endpoint carried no equivalent limit before the fix, an omission on one specific path rather than an absence of the concept anywhere in Omnigent's own design.

Inherited permissions or assumptions. The vulnerable path's own implicit assumption, this record's reading rather than a stated project rationale: that reaching an agent through an authorized session path was itself sufficient authority over the object reached, rather than a separate fact requiring its own check.

Revocation or modification. Fixed in Omnigent 0.3.0 by rejecting a bundle upload that targets a shared or template agent outright, before any part of the upload is processed. This record found no documented mechanism, in the material it could retrieve, for detecting or restoring a shared agent that was already overwritten through this path before an operator upgraded past the fix, and states that as an open question rather than assuming either that recovery guidance exists or that it does not.

Challenge authority. None. Nothing in the advisory, the pull request or the commit describes a second reviewer, an approval step or any check independent of the caller's own LEVEL_EDIT permission standing between the request and the mutation it performed.

Recovery. Not addressed by anything this record could find. The fix prevents the specific path going forward; it does not, on the evidence available to this record, reverse a shared agent already poisoned before an operator's own upgrade.

Provenance evidence quality. The mechanism itself is corroborated consistently across three independently retrieved project artifacts, the advisory, the pull request and the commit, plus an independently rendered mirror of the advisory in the GitHub Advisory Database, all agreeing on the endpoint, the agent.session_id check and the fix. Retrieved through this session's automated page fetch and summarization tool rather than a raw, line level source read, which this record states plainly rather than presenting as equivalent to a direct code read. Unestablished: exploitation before the fix, the exact function name and line count of the change, and whether any recovery guidance exists for an already poisoned shared agent.

Where this sits against what this desk has already argued

Salesforce's Headless 360 MCP Server inherits one authenticated human's own session permissions into an agent, unchanged, so an agent's ceiling is whatever that one person could already do. That is a single hop, human to agent, bounded by one person's own access. This vulnerability has no single bounding actor at all: the shared agent's capabilities, once poisoned, are inherited by every session that loads it, an unbounded and, from the exploiting user's own position, largely unknown population of future users and sessions.

The broader argument that authority has to be evaluated independently at the moment an action executes, not assumed from an earlier grant or an earlier authorized path, is the family this record belongs to, and this vulnerability sharpens a part of that argument the corpus has not yet isolated in its own terms. Evaluating authority at execution closes a gap like this one only if the evaluation covers the exact object a request is about to mutate, not only the container, the session, through which the request arrived. A check that stops at the session's own permission boundary, however correctly enforced, never reaches the question this vulnerability turns on: whether the object the session happens to reference is the session's alone, or the platform's, held in trust for every session that will ever point at it again.

What this does not establish

This is a project disclosed, patched vulnerability, not a confirmed exploitation. This record found no evidence, in the GitHub Security Advisory, the pull request, the fix commit or independent search, that the vulnerability was exploited against a real deployment before the patch, and does not claim it was. This record's access to Omnigent's own repository and advisory in this session came through automated page retrieval and summarization rather than a direct, line level read of the vulnerable and patched source, the method this desk has used elsewhere in this dataset to confirm a fix's exact mechanism; the mechanism stated here is corroborated across three independently retrieved artifacts, the advisory, the pull request and the commit, each describing the same endpoint, the same agent.session_id check and the same fix, but an editor with direct repository access should confirm the precise function name, line count and error text before treating those specifics as independently verified to the same standard as this record's account of the mechanism itself. Nor does this record establish what share of Omnigent deployments run multi tenant, with shared agents actually reachable by more than one trusted operator; a single operator deployment where every session belongs to the same trusted party would not present the same practical risk this vulnerability's mechanism otherwise describes, and this record does not assume a specific deployment topology it cannot verify.