CoreBB is open-source forum software intended to run on standard PHP hosting, including shared-hosting environments. Security depends on both the application code and the way each forum is installed, configured, and maintained.

This page summarizes the built-in protections, what kinds of vulnerabilities should be reported privately, and the operating practices forum administrators should follow.

Please do not report suspected security vulnerabilities in public GitHub issues.

Email security reports to security@corebb.net or use GitHub private vulnerability reporting.

Please include as much of the following as you can:

• Affected CoreBB version or commit.
• Steps to reproduce the issue.
• Proof-of-concept details, if available.
• Security impact and who can trigger it.
• Whether the issue appears to be actively exploited.
• Your preferred credit name, if you want credit.

CoreBB does not currently operate a paid bug bounty program. Responsible vulnerability reports are appreciated, and reporter credit may be included in release notes when requested.

Examples of security issues:

• Authentication bypass.
• Privilege escalation.
• Private board access bypass.
• Stored or reflected cross-site scripting.
• CSRF that changes account, admin, or forum state.
• SQL injection.
• Arbitrary file upload.
• Password reset or token flaws.
• Sensitive data exposure.
• Moderator or administrator permission bugs.
• Unsafe archive or private content exposure.

Usually not in scope:

• Spam or abuse that requires normal user permissions.
• Social engineering.
• Self-XSS that only affects the reporter's own browser/session.
• Outdated browser behavior.
• Vulnerabilities caused by modified third-party installs.
• Issues caused by deliberately weakened server configuration.

CoreBB includes several application-level protections:

• CSRF tokens are enforced on state-changing form requests unless a route has an explicit, reviewed exemption.
• Restricted boards, Secure Archive areas, moderator tools, and administrator tools use server-side permission checks.
• Actively maintained database access paths are expected to use shared database helpers with prepared statements and bound parameters. Legacy paths should be reviewed during modernization work.
• Passwords are hashed with PHP's password_hash() / password_verify() APIs.
• Persistent login tokens use random selectors and hashed verifier tokens.
• Session cookies are configured with HttpOnly, SameSite=Lax, and Secure when HTTPS is detected.
• Core security headers include same-origin framing, MIME sniffing protection, same-origin referrer policy, and a restrictive permissions policy.
• Twig templates escape ordinary variables by default, while formatted forum content is routed through the forum markup renderer.

No forum software can make an unsafe hosting environment safe by itself. Keep the application and server configuration current.

Forum administrators should:

• Keep CoreBB updated.
• Use HTTPS for the forum and admin panel.
• Run a current supported PHP version.
• Protect private config files outside the public web root where possible.
• Use strong, unique administrator passwords.
• Restrict administrator and moderator accounts to people who need that access.
• Keep tested backups of the database, uploads, and private configuration.
• Disable unused plugins, modifications, and old custom code.
• Review file and directory permissions after installation or migration.
• Rotate secrets if configuration files, database backups, or admin sessions may have been exposed.
• Publish a working security contact before making the site public.
• Keep security-sensitive configuration values out of the public repository and publicly accessible web directories.

Security fixes are provided for the latest stable release. Older releases may not receive backported fixes unless the vulnerability is severe.

Installers should plan to update promptly when a security release is published.

We aim to acknowledge valid security reports, investigate them privately, prepare a fix, and publish release notes once a patched version is available.

Please give maintainers a reasonable chance to investigate and patch before public disclosure. Reports involving active exploitation may be handled with more urgent public guidance.

CoreBB is open source, so repository hygiene matters. Maintainers should review dependency updates, protect release branches, test release builds, and keep security-sensitive changes reviewable.

Release packages should be built from reviewed source and should not include development-only files, test artifacts, private configuration, or local environment secrets.

Tools such as OpenSSF Scorecard can help evaluate public maintainership and supply-chain signals over time.