Security advisoryInformationalAPIWebAction required: No
Browser enrollment now has an explicit deny decision
You can deny a browser enrollment request, and a denied device code cannot later grant account access.
Show details ▾Hide details ▴
- The activation page confirms or denies the pending device request.
- A denial is terminal for that device code; it does not create a credential.
- Confirmation is bound to the signed-in account identity.
Security advisoryMediumAPIMCP GatewayAction required: No
Free-tier compression quota now fails closed when usage cannot be measured
If Redis and the Postgres fallback both cannot determine monthly usage, free-tier compress and MCP calls return a retryable error instead of bypassing the monthly limit.
Show details ▾Hide details ▴
- Redis down + Postgres fallback exhausted on free plan -> HTTP 503 quota_unavailable
- Postgres fallback uses the same billable UsageEvent filters as usage cache rebuild
- Paid tiers remain fail-open when usage is unmeasured
Security advisoryMediumAPIMCP GatewayAction required: No
API key auth refuses when Postgres cannot confirm enforcement state
If Redis authenticates a key but Postgres cannot confirm project binding or allowlists, the request is rejected (401 when the row is gone, 503 on DB outage) instead of serving possibly stale Redis enforcement fields.
Show details ▾Hide details ▴
- Deleted/revoked key with stale Redis blob -> HTTP 401
- Postgres outage during enforcement lookup -> HTTP 503 auth_state_unavailable
- Successful DB lookup still overwrites Redis-seeded state from Postgres
Security advisoryHighAPIAction required: No
Polar subscription webhook processing failures now return 503
If a subscription lifecycle handler fails after signature verify, the webhook returns 503 so Svix retries instead of acknowledging with 200 and risking a dropped grant or downgrade.
Show details ▾Hide details ▴
- Lifecycle handler exceptions -> HTTP 503 Webhook processing failed
- Unreadable discriminator after verify -> HTTP 503
- Named-but-unhandled events still return 200
Security advisoryMediumAPIAction required: No
Resend inbound webhooks now deduplicate Svix replays
Replayed Resend deliveries with the same svix-id short-circuit with 200 before re-running bounce/complaint suppression. Dedup failures return 503 so retries stay safe.
Show details ▾Hide details ▴
- dedup_inbound_event(provider=resend) after signature verify
- Replay -> 200 ok without re-applying opt-out
- Dedup DB error -> 503 dedup unavailable
Security advisoryHighAPIAction required: No
Resend bounce suppression failures now return 503 (fail closed)
If bounce/complaint opt-out handling fails after signature verify, the webhook returns 503 so Resend retries instead of acknowledging with 200 and permanently skipping email suppression.
Show details ▾Hide details ▴
- Suppression-handler exceptions -> HTTP 503 suppression unavailable
- Soft/ignored/success paths still return 200
- Misconfig and bad signatures remain 400
Security advisoryHighAPIAction required: No
Inbound webhook dedup failures now return 503 instead of re-processing
If the dedup ledger is unavailable after signature verification, Clerk, Polar, and GitHub webhooks return 503 and skip handlers. This prevents non-idempotent side effects from running twice when Svix retries, at the cost of a temporary delay until dedup recovers (GitHub needs a manual redeliver).
Show details ▾Hide details ▴
- Dedup DB errors fail closed with 503; handlers are not dispatched
- Rollback after a dedup error is best-effort and cannot demote the 503 to a 500
- GitHub log/detail includes the redeliver phrase for operator recovery
Security advisoryHighAPIAction required: No
Offline migration scripts now include the RLS safety sweep
When you generate SQL with alembic upgrade --sql, the output now includes the same post-migration Row Level Security sweep that runs on every Fly deploy. Previously, applying offline-generated scripts could leave new public tables without RLS enabled.
Show details ▾Hide details ▴
- Offline Alembic runs on Postgres URLs emit lock_timeout + ENABLE ROW LEVEL SECURITY sweep SQL after migrations
- Mirrors the every-deploy migration hook so air-gapped or reviewed SQL paths cannot skip tenant isolation hardening
Security advisoryMediumAPIAction required: No
Accept-grant elevates to system before RLS-sensitive write
Preparing for RLS enablement: recording share acceptance now sets app.role=system for the accept UPDATE so it still works once policies are enforced.
Show details ▾Hide details ▴
- accept_grant elevates app.role mid-transaction before stamping accepted_at (0149 requires a service write, not a grantee UPDATE).
- Does not flip RLS_GUC_ENABLED or change the production DB role; those remain CEO-gated (#514).
Security advisoryMediumAPIAction required: No
Chat completions now has its own 60/min ceiling
POST /v1/chat/completions forwards each call to an upstream model provider on your own stored API key, so you are billed directly for it. It previously inherited the general per-plan request limit, which on the top tier allowed 500 calls a minute. It is now capped at 60 a minute -- one per second -- so a runaway loop or a leaked key costs far less before you notice. Normal interactive use is nowhere near this.
Show details ▾Hide details ▴
- The new ceiling applies only to POST /v1/chat/completions. Compression, knowledge and every other endpoint keep their existing per-plan limits.
- Per-path ceilings can now only lower a limit, never raise one. Previously a path entry replaced the plan value outright, so an entry above your plan tier would have increased your allowance instead of capping it.
- Responses continue to carry x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset, so a client can see the ceiling it is working against.
Security advisoryMediumAPIAction required: No
Webhook signing secrets are now encrypted at rest
The secret your endpoint uses to verify the signature on our webhook deliveries is now encrypted in our database rather than stored as readable text. Nothing changes for you: the secret value itself is unchanged, so your existing verification keeps working and no reconfiguration is needed.
Show details ▾Hide details ▴
- New webhook secrets are encrypted before they are stored, using the same versioned key scheme already used for provider credentials.
- The secret is still shown to you once, in full, when you create the webhook. It stays redacted everywhere else.
- Delivery signatures are unchanged, so endpoints that already verify our signature continue to verify successfully.
Security advisoryMediumAPIAction required: No
Signed A2A Agent Card for verifiable identity
Other AI agents that discover gotcontext through the Agent2Agent (A2A) protocol can now cryptographically verify that the Agent Card really came from gotcontext, before they trust or delegate to it. Our public Agent Card now carries a JWS signature that a standard A2A client can check against our published key.
Show details ▾Hide details ▴
- The Agent Card at the well-known A2A discovery path now includes a JWS signature (Ed25519) over the RFC 8785 canonical form of the card.
- Verifiers can fetch the verification key from our published key set and reject a forged or tampered card.
- The signature is additive and backward compatible: existing clients that ignore it keep working; self-hosted deployments without a signing key serve an unsigned card.
Security advisoryHighMCP GatewayAction required: No
Restricted server-side-path tools on the hosted MCP service
A few Pro-tier MCP tools accept a server-side file path, which is only meaningful in a self-hosted deployment. On the hosted service they are now correctly hidden and blocked, since they do not apply there. Self-hosted deployments are unaffected and keep full access.
Show details ▾Hide details ▴
- Tools that take a server-side path are no longer discoverable or callable on the hosted MCP endpoint.
- Added an automated release check so any future tool of this kind is caught before it ships.
- Self-hosted operators keep these tools in full.
Security advisoryHighAPIAction required: No
Upgraded a core web framework to clear published CVEs
Upgraded the API's underlying web framework to a new major version, clearing four high-severity published vulnerabilities, including authentication-bypass and request-forgery classes. No action is required on your side.
Show details ▾Hide details ▴
- Core web framework upgraded to its latest major release.
- Four high-severity published vulnerabilities resolved.
- No changes to your integration or request format.
Security advisoryMediumAPIMCP GatewayAction required: No
Knowledge Base private items and sharing are now enforced
Items marked private are visible only to the API key that created them. Per-key sharing allowlists are enforced on every Knowledge Base operation: query, read, edit, delete, and diff, across both the MCP and REST surfaces.
Show details ▾Hide details ▴
- Private Knowledge Base items are accessible only to the API key that created them.
- Sharing allowlists are checked on every operation (query, read, edit, delete, diff), not just on query.
- Enforcement is consistent across the MCP gateway and the REST API.
Security advisoryMediumWebAction required: No
Web dependency security updates
Several transitive browser and server-runtime dependencies were updated to patched versions. No customer action is required.
Show details ▾Hide details ▴
- Updated affected transitive packages used by the web runtime and build toolchain.
- Kept the update within compatible version ranges to avoid changing application behavior.
- Hosted customers receive the fix automatically.
Security advisoryHighAPIMCP GatewayAction required: No
Security and reliability fixes: filesystem filter, billing portal, cron cost, Docker pinning
Seven fixes from a proactive internal audit. The MCP search_code tool is now properly filtered in SaaS mode. Per-API-key tool restrictions now apply at discovery (tools/list) as well as dispatch. The billing portal returns a clear error instead of a misleading upgrade prompt when the database is briefly unavailable. GitHub Actions cron schedules were cut to reduce infrastructure cost. Docker base images are now digest-pinned for supply-chain stability. Hosted customers are auto-upgraded.
Show details ▾Hide details ▴
- The MCP search_code tool is now correctly restricted when running in hosted mode, preventing server-path access.
- Per-API-key tool allowlists now filter tools/list (discovery) and tools/call (dispatch) consistently.
- The billing portal returns a 503 with a clear message instead of a 404 "upgrade first" when the database is briefly unavailable.
- The compression engine now rejects non-finite embeddings at ingest, preventing silent result corruption downstream.
- Wire-shape contracts for the forum and social surfaces are now locked against future renames.
- GitHub Actions cron schedules reduced by roughly 59% to cut infrastructure cost.
- Docker base images are now digest-pinned so base-image changes arrive as reviewable pull requests.
Security advisoryHighAPIMCP GatewayAction required: No
Security hardening: account deletion, billing, and webhook fixes
Five fixes from a proactive internal security audit. API keys are now revoked the moment their owner account is deleted; referral credits can only be earned once per referred user; the MCP proxy tool now blocks requests to internal network addresses; key revocation is reliable under concurrent requests; and usage-alert delivery is durable across server restarts. Hosted customers are auto-upgraded. No action required.
Show details ▾Hide details ▴
- Deleting an account now revokes all of its API keys before the account is removed.
- Referral credit can only be earned once per referred user.
- The MCP proxy tool no longer forwards requests to private or internal network addresses.
- Key revocation is now reliable even under concurrent requests, so a revoked key is consistently rejected.
- Usage-alert delivery is durable and is no longer dropped when a server instance restarts.
Security advisoryMediumAPIAction required: No
Forum security: user silencing, safer username conflicts, link sanitization
Three forum hardening fixes: moderators can silence and unsilence users; username conflicts no longer reveal whether a name is already taken by another account; and unsafe links are stripped from comment content.
Show details ▾Hide details ▴
- Moderators can silence a user so they can no longer post comments, and reverse it.
- Username conflicts are reported without revealing whether the name belongs to another account.
- Unsafe links are stripped from comment content.
Security advisoryMediumAPIAction required: No
Payment-token audience enforcement
Skyfire payment tokens are now validated against the expected audience, so a token issued for a different service cannot be reused against this API. Agent payments remain off by default.
Show details ▾Hide details ▴
- Payment tokens whose audience does not match this service are rejected.
- Operators enabling agent payments configure the expected audience as part of setup.
Security advisoryHighAPIAction required: No
Secret encryption now fails closed in production
If the encryption key is not configured in production, secret-storage operations now fail safely instead of proceeding, preventing secrets from ever being written unencrypted. Local development behavior is unchanged.
Show details ▾Hide details ▴
- In production, a missing encryption key blocks the operation rather than storing unencrypted data.
- Local development is unaffected for convenience.
- Operators who rely on encryption should confirm the key is configured before deploying.
Security advisoryMediumAPIAction required: No
Per-plan request body-size limits now enforced reliably, including for streamed requests
Request body-size limits are now enforced reliably, including for streamed requests. Over-limit requests are rejected before any route handler processes the body.
Show details ▾Hide details ▴
- Identified through a proactive internal security audit and fixed server-side.
- All upload styles (including streamed requests) are now subject to the same per-plan size limits.
- Over-limit requests receive a deterministic 413 response before any route handler processes the body.
- Within-limit uploads are unaffected.
- No customer action is required.
Security advisoryMediumWebAction required: No
Dashboard notification rendering hardened against HTML injection
Notification links are now strictly escaped and URL-validated before rendering in the dashboard.
Show details ▾Hide details ▴
- Found through a proactive internal security audit; fixed in the rendering layer.
- Notification links are now validated as http(s) URLs; invalid URLs render as plain text with no anchor element.
- No customer action is required.
Security advisoryHighAPIMCP GatewayAction required: No
Knowledge-base and tool access restrictions now fail closed on a database error
A database error during API key resolution could reset a key's knowledge-base and tool allowlists to unrestricted. Those restrictions now hold their seeded values when a database error occurs.
Show details ▾Hide details ▴
- Found through a proactive internal security audit as a follow-on to the v1.50.0 hardening.
- Per-key knowledge-base and tool allowlists are now preserved correctly when a database error occurs during key resolution, rather than resetting to unrestricted.
- Keys with no allowlist configured remain unrestricted. Existing behaviour is unchanged.
- No customer action is required.
Security advisoryMediumAPIAction required: No
GitHub tokens and webhook secrets now encrypted at rest
GitHub personal access tokens and webhook secrets stored for the GitHub integration were previously held as plaintext in the database. They are now encrypted with a server-side key; existing values are transparently upgraded.
Show details ▾Hide details ▴
- Found through a proactive internal security audit and fixed server-side.
- Integration secrets are now stored as encrypted ciphertext; a database read or backup exposes ciphertext only.
- Existing plaintext values were re-encrypted during the deployment. No manual step required.
- Secret encryption now fails closed in production: if the encryption key is not configured, secret-storage operations fail safely instead of proceeding unencrypted.
- No customer action is required.
Security advisoryMediumAPIAction required: No
Outbound webhook URLs validated against internal-network access
User-configured webhook delivery URLs were not validated against internal network ranges, allowing delivery to private or cloud-metadata addresses. Webhook URLs are now checked at creation and re-validated immediately before each delivery.
Show details ▾Hide details ▴
- Found through a proactive internal security audit and fixed server-side.
- Webhook creation now rejects URLs that resolve to private, loopback, link-local, or cloud-metadata addresses.
- The delivery path re-validates the target address immediately before each outbound request.
- HTTP redirects are no longer followed during delivery.
- No customer action is required.
Security advisoryHighAPIMCP GatewayAction required: No
Scoped API keys now strictly enforced; destructive-action confirmation locked to dashboard sign-in
Scoped API keys were accepted by the server but their scope constraints were not persisted or enforced. Every scoped key silently ran with full access. Scope restrictions are now applied end-to-end. Separately, the confirmation gate for destructive key operations now requires an active dashboard session.
Show details ▾Hide details ▴
- Found through a proactive internal security audit and fixed server-side.
- Scope restrictions are now stored and enforced on every request. Previously they were accepted at creation but not applied.
- Existing keys without explicit scopes are treated as legacy full-access keys. No behaviour change for current users.
- A temporary backend outage during key resolution no longer causes a scoped key to fall back to full access.
- The confirmation gate for destructive key operations now requires an active dashboard session.
- No customer action is required.
Security advisoryMediumAPIAction required: No
Analytics CSV export hardened against spreadsheet formula injection
CSV cells beginning with formula-trigger characters (=, +, -, @) are now neutralized so exported files cannot execute formulas when opened in Excel or Google Sheets.
Show details ▾Hide details ▴
- Identified through a proactive internal security review and fixed server-side.
- Cells that start with =, +, -, or @ are prefixed with a tab character before export, following standard CSV injection mitigation practice.
- Numeric and date values are unaffected.
- No customer action is required.
Security advisoryHighAPIMCP GatewayAction required: No
Live key revocation across all API servers + outbound URL hardening
Revoked gc_ API keys are now invalidated promptly and reliably across all API servers. Separately, the document-fetch and Knowledge Hub ingest paths now block requests to private or internal network addresses across all known address encoding variants.
- Fixed in:
- API v1.35.0
- Components:
- API key lifecycle · MCP Gateway
Show details ▾Hide details ▴
- Revoked API keys are now invalidated promptly across all API servers. Revocation no longer requires waiting for a cache TTL to expire.
- Server restarts no longer cause revocation events to be missed.
- The document-fetch and Knowledge Hub ingest paths now block requests to private or internal network addresses.
- Pairs with the v1.34.36 hotfix (cache-invalidation gap in the key confirmation flow) shipped the same day.
Security advisoryHighAPIAction required: No
P0 hotfix: revoked confirm-tokens now invalidated promptly across all servers
A revoked key issued through the key-confirmation flow was not immediately invalidated in the shared cache, allowing it to continue authenticating on peer servers until the cache refreshed. The fix invalidates the cache immediately after revoking the key in the database.
- Affected:
- API v1.34.35
- Fixed in:
- API v1.34.36
- Components:
- API key lifecycle
Show details ▾Hide details ▴
- Cache invalidation is best-effort: a cache failure is logged and does not surface as an error to the caller.
IncidentCriticalMCP GatewayAction required: No
MCP tools returned 500 for ~10 minutes
All MCP tool calls failed with HTTP 500 for approximately 10 minutes. No data was lost. Customers using MCP clients (Claude Code, Cursor, Codex CLI, Gemini CLI) saw tool calls fail and could retry after the window closed.
- Affected:
- API v1.22.4 to v1.23.0
- Fixed in:
- API v1.23.1
- Components:
- MCP Gateway · tools/call dispatch
Show details ▾Hide details ▴
- A routing change caused every tool call to reach a code path with a reference that had never existed. The defect was dormant in a prior release but only became reachable after the routing change landed.
- Resolution: the broken reference was removed and deployed as API v1.23.1.
- Hardening: automated checks were added to catch this entire class of defect before it ships.
Compliance noticeHighAPIAction required: No
Unsubscribe endpoint returned 401 for all requests
Between API v1.23.0 and v1.23.1, the `/v1/unsubscribe` endpoint (used for the CAN-SPAM/GDPR-required unsubscribe link in transactional emails) returned 401 Unauthorized for all requests. No unsubscribe records were lost. The endpoint returned a non-200 to clients, which retried or surfaced the error. No customer action required.
- Affected:
- API v1.23.0
- Fixed in:
- API v1.23.1
- Components:
- API · /v1/unsubscribe · transactional email footer
Show details ▾Hide details ▴
- The endpoint now correctly accepts unauthenticated requests as required for the unsubscribe use case.
- No personal data was processed during the regression window. All requests during the window returned an explicit 401; retrying the unsubscribe link resolves the original opt-out.
Security advisoryHighAPIMCP GatewayAction required: Yes
SSRF: outbound URL fetch paths now block requests to private and internal network addresses
Outbound URL fetches (used by webhook delivery, KB document ingestion, and a small number of MCP tools) could be tricked into reaching loopback or private addresses through address encoding techniques. The webhook/document-fetch paths now block requests to private or internal network addresses. Hosted customers received the fix automatically; self-hosted operators should upgrade to API ≥ v1.22.6.
Action required
Self-hosted operators: upgrade the API container to v1.22.6 or newer. No action required for customers on the hosted gotcontext.ai service.
- Affected:
- API ≤ v1.22.5
- Fixed in:
- API v1.22.6
- CVE:
- CVE pending assignment
- CVSS:
- 7.5 (High), CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
- Components:
- Webhook delivery · Knowledge Hub
Show details ▾Hide details ▴
- All outbound URL fetch paths now enforce private/internal network blocking at both validation time and connection time.
- No active exploitation was observed in production traffic. The advisory is published preemptively.