Security and limitations

Authentication and session controls

New passwords use Argon2id (64 MiB, three iterations, one lane). Existing Passlib PBKDF2-SHA256 records are verified by a bounded compatibility reader and migrate on successful login; Passlib and python-jose are no longer runtime dependencies. HTTP login never recovers or promotes administrators. Password changes invalidate sessions, API access tokens, integration tokens, and MCP OAuth access. Web forms and same-origin fetch writes require CSRF tokens; logout is a POST operation.

Server-side authorization

Original API operations re-read current user roles and enforce their existing ownership/admin rules. GPT Actions and MCP separately enforce task ownership, even for administrators. MCP assignment additionally checks current manager/administrator eligibility and transfers only owned active standalone tasks. Request bodies, credential lengths, task list pages, notification response sizes, and login attempts are bounded. Reverse-proxy limits are still necessary for public deployments.

MCP authorization

The optional MCP endpoint uses per-user OAuth authorization codes with S256 PKCE, exact callback matching, explicit consent, and tokens bound to the configured /mcp resource. Access and refresh credentials are hashed in SQLite. Refresh rotation and authorization-code reuse checks revoke replayed connections; password changes, account removal, signing-key rotation, and profile disconnection invalidate the relevant access.

Authorization responses identify their issuer under RFC 9207. The metadata issuer and each callback iss value match exactly; request headers cannot choose that identifier. Exact callback checks remain in place. Each tool checks its required scope and current database permissions. Browser consent and disconnection retain CSRF checks; only exact enabled machine protocol paths bypass cookie CSRF. Registration, authentication, and integration traffic have request limits, with process-local rate limiting. Preserve Host and scheme through a trusted TLS proxy and add deployment-wide limits where needed.

Creation and assignment use atomic audit/retry records. Task descriptions, URLs, and tool output remain untrusted content; they must never override user instructions or server permissions. Tool annotations describe intended client confirmation behavior but do not replace authorization. No administrator, export, arbitrary URL fetch, or permanent deletion tool is exposed.

Network and data controls

Notification transport checks destination DNS/IPs, pins the validated address, verifies TLS, rejects redirects and unsafe headers, and blocks metadata/loopback destinations. Exact operator allowlists support trusted LAN services. Windows notification channel URIs must use the expected Microsoft hostname family before a bearer credential is attached. Notification API output redacts credentials; backup/settings/initial-password files use owner-only atomic writes.

Known residual risks

The browser Content Security Policy still allows inline scripts/styles because existing templates rely on them; conversion to external scripts or per-response nonces is separate work. Credentials stored in the application database and exported backups are not automatically encrypted at rest. The rate limiter and scheduler are process-local. Notification socket timeouts are not a guarantee of a strict wall-clock deadline for every DNS/provider failure. Upstream advisories, provider APIs, and base images can change after an audit.

Automated dependency scanning does not establish absence of exploitable vulnerabilities. The original ecdsa advisory was a transitive dependency finding; this application used HS256, so that advisory alone did not demonstrate an exploitable ECDSA signing path. Removing the unused crypto stack reduces that exposure without inventing an exploit claim.

Validation scope

The repository workflow runs regression tests, dependency and static scans, docs checks, browser smoke tests, and container checks. Consult the exact commit's run and artifacts rather than historical validation reports. Provider delivery, real-data disaster recovery, penetration testing of a deployed host, accessibility auditing, and live ChatGPT acceptance require separate environment-specific evidence.

Reporting

Report suspected vulnerabilities privately to the repository owner, using GitHub's private vulnerability-reporting facility when enabled. Do not place credentials or detailed unpatched deployment exploit information in public issues. The source audit and fix/deprecate decisions are recorded in AUDIT_REPORT.md.