How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

346,508

Total vulnerabilities in the database

Paperclip: codex_local inherited ChatGPT/OpenAI-connected Gmail and was able to send real email — paperclipai

Improper Access Control

Summary

A Paperclip-managed codex_local runtime was able to access and use a Gmail connector that I had connected in the ChatGPT/OpenAI apps UI, even though I had not explicitly connected Gmail inside Paperclip or separately inside Codex.

In my environment this enabled mailbox access and a real outbound email to be sent from my Gmail account. After I manually intervened to stop the workflow, follow-up retraction messages were also sent, confirming repeated outward write/send capability.

This appears to be a trust-boundary failure between Paperclip-managed Codex execution and inherited OpenAI app connectors, amplified by dangerous-by-default runtime settings.

Details

Successful runtime calls include:

mcp__codex_apps__gmail_get_profile
mcp__codex_apps__gmail_search_emails
mcp__codex_apps__gmail_send_email

The connected Gmail profile resolved to my personal account.

Inside the Paperclip-managed codex-home, I also found cached OpenAI curated connector state for Gmail under a path like:

codex-home/plugins/cache/openai-curated/gmail/.../.app.json

This strongly suggests that the runtime had access to an already connected OpenAI apps surface rather than a Paperclip-specific Gmail integration that I intentionally configured.

Separately, in the installed Paperclip code, codex_local defaults dangerouslyBypassApprovalsAndSandbox to true, and the server-side agent creation path applies that default when the flag is omitted. In practice, that makes this boundary failure much more dangerous because a newly created codex_local agent can operate with approvals and sandbox bypassed by default.

The key issue is this: I had connected Gmail only in the ChatGPT/OpenAI apps UI. I had not intentionally connected Gmail inside Paperclip or separately inside Codex. Despite that, the Paperclip-managed codex_local runtime was able to use Gmail read/write actions.

PoC

Environment:

self-hosted Paperclip instance using codex_local
Gmail connected in the ChatGPT/OpenAI apps UI
no explicit Gmail connection configured inside Paperclip for this test
codex_local agent created and run with default behavior

Observed reproduction path:

Connect Gmail in the ChatGPT/OpenAI apps UI.
Create or run a Paperclip codex_local agent.
Execute a task that inspects mailbox state or performs outward communication.
Observe successful Gmail connector calls such as:
- mcp__codex_apps__gmail_get_profile
- mcp__codex_apps__gmail_search_emails
- mcp__codex_apps__gmail_send_email
Observe that the connected profile resolves to the ChatGPT/OpenAI-connected Gmail account and that mailbox reads and real sends are possible.

Private evidence available on request:

successful get_profile / search / send logs
Paperclip-managed codex-home Gmail connector cache path(s)
screenshot showing Gmail write-capable actions such as send_email, send_draft, and update_draft exposed in the connected-app UI
incident timeline showing that a real outbound email was sent
recipient organizations, timestamps, message IDs, and sanitized evidence for both the original outbound email and the subsequent retraction messages

Impact

This was not only theoretical in my environment. It resulted in:

mailbox identity disclosure
mailbox search / thread access
a real outbound email being sent from a personal connected Gmail account to an external third party
follow-up retraction messages being sent after manual intervention, confirming repeated outward write/send capability

From an operator/security perspective, connecting Gmail in the ChatGPT/OpenAI apps UI should not automatically make that connector available to a Paperclip-managed local agent runtime, especially not for write/send actions.

One or more of the following:

no inherited OpenAI app connectors by default in Paperclip-managed codex_local runs
send/write connectors blocked by default
explicit Paperclip-side opt-in before outward actions
auditable approval and provenance for connector-mediated actions
safer defaults, including dangerouslyBypassApprovalsAndSandbox = false

Published: Apr 16, 2026
Updated: Apr 17, 2026
GHSA: GHSA-gqqj-85qm-8qhf
Severity: High
Exploit:

CVSS v3:

Severity: Unknown
Score:
AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

CWEs:

CWE-284

OWASP TOP 10:

A5 - Broken Access Control

Affected Software
References

Software	From	Fixed in
paperclipai	-	2026.403.0.x

https://github.com/paperclipai/paperclip/security/advisories/GHSA-gqqj-85qm-8qhf

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.