Inventoros is currently in early development. Security updates will be applied to the following versions:

Note: Until version 1.0 is released, only the main branch receives security updates. We recommend always running the latest version from the main branch.

The Inventoros team takes security vulnerabilities seriously. We appreciate your efforts to responsibly disclose your findings and will make every effort to acknowledge your contributions.

Please DO NOT report security vulnerabilities through public GitHub issues.

Instead, please report security vulnerabilities by:

1. Email: Send an email to [security@inventoros.com] with:

   • A description of the vulnerability
   • Steps to reproduce or proof of concept
   • Potential impact of the vulnerability
   • Any suggested fixes (if applicable)

2. GitHub Security Advisories: Use GitHub's private vulnerability reporting feature:

   • Go to the Security Advisories page
   • Click "Report a vulnerability"
   • Fill out the form with details

To help us better understand and address the issue, please include:

• Type of vulnerability (e.g., SQL injection, XSS, authentication bypass)
• Full paths of source file(s) related to the vulnerability
• Location of the affected source code (tag/branch/commit or direct URL)
• Step-by-step instructions to reproduce the issue
• Proof-of-concept or exploit code (if possible)
• Impact of the vulnerability - what could an attacker achieve?
• Any special configuration required to reproduce the issue
• Your environment details (PHP version, database, OS, etc.)

We will make our best effort to respond according to the following timeline:

• Initial Response: Within 48 hours of report submission
• Confirmation: Within 1 week, we will confirm the vulnerability and its severity
• Resolution: We will work on a fix and coordinate disclosure timing with you
• Disclosure: After a fix is released, we will publicly disclose the vulnerability

After you submit a report:

1. Acknowledgment: We'll acknowledge receipt of your vulnerability report
2. Assessment: Our team will investigate and validate the vulnerability
3. Updates: We'll keep you informed about our progress
4. Fix Development: We'll develop and test a fix
5. Coordinated Disclosure: We'll coordinate with you on the disclosure timeline
6. Public Disclosure: After the fix is deployed, we'll publish a security advisory
7. Credit: We'll credit you in the security advisory (unless you prefer to remain anonymous)

1. Triage: Assess severity using CVSS scoring
2. Confirmation: Verify the vulnerability in our environment
3. Development: Create a patch or mitigation
4. Testing: Verify the fix doesn't introduce regressions
5. Release: Deploy the fix to the main branch
6. Notification: Notify users via GitHub Security Advisories and release notes
7. Documentation: Update security documentation as needed

When deploying Inventoros, follow these security best practices:

• Never commit .env files to version control
• Use strong, unique passwords for database and admin accounts
• Enable HTTPS in production environments
• Keep APP_DEBUG set to false in production
• Set a secure APP_KEY using php artisan key:generate
• Use environment-specific .env files (never share between environments)

• Keep dependencies updated: Run composer update and npm update regularly
• Monitor security advisories: Watch for Laravel and package security updates
• Review dependency licenses: Ensure compatibility with your use case

• Use strong authentication: Implement multi-factor authentication when possible
• Follow principle of least privilege: Grant minimal necessary permissions
• Rotate API tokens regularly: Especially for production systems
• Review user permissions: Audit access controls periodically

• Use separate database users with minimal required privileges
• Enable SSL/TLS for database connections in production
• Regularly backup data and test restoration procedures
• Sanitize database dumps before sharing (remove sensitive data)

• Keep PHP and system packages updated
• Disable unnecessary PHP extensions
• Configure proper file permissions (storage and bootstrap/cache directories)
• Use a WAF (Web Application Firewall) in production
• Monitor logs for suspicious activity

• Validate all user input (Inventoros uses Laravel's validation, but verify custom code)
• Use parameterized queries (Laravel's Eloquent handles this, avoid raw queries)
• Implement rate limiting for API endpoints
• Enable CSRF protection (enabled by default in Laravel)
• Use Content Security Policy (CSP) headers

Inventoros integrates Sentry for structured error and performance reporting, which is important for catching exceptions you would otherwise never see in production (failed jobs, 500s, integration errors). It is disabled by default and only activates once you provide a DSN:

SENTRY_LARAVEL_DSN=https://<key>@<org>.ingest.sentry.io/<project># Optional — defaults shown. Errors are captured at 100%, traces sampled at 10%.SENTRY_TRACES_SAMPLE_RATE=0.1

Create a project at sentry.io (or self-host GlitchTip, which is DSN-compatible) to get the DSN. send_default_pii is off by default so request bodies / user data are not shipped; turn it on only if your privacy policy allows. With no DSN set, the integration is inert and adds no overhead.

As Inventoros is in active development:

• API endpoints may change without notice
• Authentication mechanisms are still being finalized
• Multi-tenant isolation is under development and not production-ready
• Audit logging is not yet fully implemented

We do not recommend using Inventoros in production until version 1.0 is released.

If you choose to deploy in production:

• Understand that you assume all associated risks
• Implement additional security layers (WAF, monitoring, backups)
• Regularly check for updates and apply them promptly
• Have a rollback plan in case of issues

Security updates will be announced through:

• GitHub Security Advisories: https://github.com/inventoros/inventoros/security/advisories
• Release Notes: Tagged releases with security patches
• GitHub Discussions: Security announcements category
• Email Notifications: For critical vulnerabilities (if you've reported issues previously)

Subscribe to repository notifications to stay informed about security updates.

The following are within the scope of our security program:

• Authentication and authorization bypasses
• SQL injection vulnerabilities
• Cross-Site Scripting (XSS)
• Cross-Site Request Forgery (CSRF)
• Remote code execution
• Privilege escalation
• Data leaks or unauthorized data access
• Session management issues
• Insecure cryptographic storage
• API security vulnerabilities

The following are explicitly out of scope:

• Vulnerabilities in third-party dependencies (report to the respective maintainers)
• Social engineering attacks
• Physical security issues
• Denial of Service (DoS) attacks
• Reports from automated scanners without manual verification
• Issues in development or testing environments
• Issues requiring unlikely user interaction
• Vulnerabilities requiring physical access to the server

Inventoros has a WordPress-style plugin system: a .zip archive uploaded by an admin user is extracted into /plugins/ and the manifest's main_file is require_once'd into the running application process. This grants arbitrary PHP execution. Anyone who can authenticate as an admin user (compromised password, stolen session, phishing) can use the plugin upload endpoint to obtain remote code execution on the server.

This is a documented, opt-in feature. Plugin uploads are disabled by default and gated behind an environment flag:

INVENTOROS_ALLOW_PLUGIN_UPLOADS=true

When the flag is unset or false, POST /admin/plugins/upload returns an error without writing anything. The admin UI displays the disabled state.

When you enable the flag, you accept the residual risk: secure your admin accounts (strong passwords, 2FA, IP allowlist if practical), audit manage_plugins permission grants, and consider whether you really need the upload UI versus simply placing trusted plugins into /plugins/ via deploy automation.

The upload path itself validates ZIP archives against:

• Path traversal (.., absolute paths, backslash path separators).
• Entry count limit (INVENTOROS_PLUGIN_MAX_ENTRIES, default 2000).
• Total uncompressed size limit (INVENTOROS_PLUGIN_MAX_BYTES, default 50 MB).
• A single top-level directory in the archive.
• Post-extraction containment inside /plugins/.

These guard against zip-slip / zip-bomb attacks but do not sandbox plugin code at runtime. Once enabled and uploaded, a plugin runs with the full privileges of the Inventoros PHP process.

On top of the upload flag, an operator can require every uploaded plugin to carry a detached Ed25519 signature, so that only plugins signed by a trusted key can be installed even by a compromised admin session:

INVENTOROS_PLUGIN_SIGNATURE_REQUIRED=trueINVENTOROS_PLUGIN_PUBLIC_KEY=<base64 Ed25519 public key>

This is off by default (there is no public Inventoros plugin registry yet, and requiring signatures unconditionally would block local plugin development). When on, it fails closed: an upload with a missing/invalid signature — or a missing public key — is rejected before extraction. Sign a plugin archive with the same tooling used for release signing:

INVENTOROS_UPDATE_SECRET_KEY=... php artisan update:sign my-plugin.zip
# upload my-plugin.zip and paste the contents of my-plugin.zip.sig into the signature field

UpdateService downloads a release archive from a configurable URL, extracts it over the running application, and runs migrations. restoreFromBackup does the analogous extract-over-app for a backup ZIP. Both are RCE-class surfaces if an attacker can influence the source.

The hardening posture is the same WordPress-style "trust the source, validate the archive" approach used for plugins:

• Download URL allowlist. Only URLs starting with one of update.download_url_prefixes (config/update.php) are accepted. The default allows this project's GitHub release endpoints. Override via INVENTOROS_UPDATE_PREFIXES.

• No redirect following. The HTTP client refuses 3xx redirects on the download — a 302 from an allowlisted host can't smuggle you off to an arbitrary URL.

• ZIP archive validation before extraction via App\Support\SafeZipExtractor:

  • Path traversal (.., absolute paths, backslash separators).
  • Entries that escape the destination directory after realpath canonicalisation.
  • Entry-count cap (INVENTOROS_UPDATE_MAX_ENTRIES, default 50000).
  • Uncompressed-size cap (INVENTOROS_UPDATE_MAX_BYTES, default 300 MB).

• Cryptographic signature verification of the archive before extraction. Each release ships a detached Ed25519 signature (<asset>.zip.sig, base64 of the raw 64-byte signature) next to the asset. UpdateService downloads the signature from the same allowlisted host and verifies the archive bytes against the public key in update.signature.public_key (INVENTOROS_UPDATE_PUBLIC_KEY) before any file is touched.

  • Fail-closed.update.signature.required is true by default: if it is on but no public key is configured, updates are refused rather than installing an unverified download. Operators deliberately running unsigned builds set INVENTOROS_UPDATE_SIGNATURE_REQUIRED=false.

Maintainers mint a keypair once and publish a signature with every release:

# Once: generate a keypair. Commit/ship the PUBLIC key; keep the SECRET key# in the release-signing environment (e.g. a CI secret) — never in the repo.
php artisan update:signing-keypair
# Per release: sign the built archive. Reads INVENTOROS_UPDATE_SECRET_KEY and# writes release.zip.sig alongside it. Upload BOTH to the GitHub release.
INVENTOROS_UPDATE_SECRET_KEY=... php artisan update:sign dist/release.zip

What is explicitly not included:

• Tarball / tar.gz support. The updater only consumes ZIPs.

Inventoros does not currently offer a bug bounty program. However, we deeply appreciate security researchers' efforts and will publicly acknowledge contributors who report valid vulnerabilities (with their permission).

For security-related questions or concerns:

• Email: [security@inventoros.com]
• GitHub Security: https://github.com/inventoros/inventoros/security/advisories/new

For general questions about Inventoros:

• GitHub Discussions: https://github.com/inventoros/inventoros/discussions
• GitHub Issues: https://github.com/inventoros/inventoros/issues (non-security issues only)

Thank you for helping keep Inventoros and its users safe!