OrbUX takes reports about source, packages, build tooling, generated browser bundles, and the gallery seriously. This document explains what is supported and how to report a vulnerability without putting users at risk.

OrbUX has not made a stable public release yet. Security fixes are applied to the latest code on main and, after packages are published, to the latest 0.1.x release line.

This table will be updated when the project establishes additional maintained release lines.

Do not open a public issue, discussion, or pull request for a suspected vulnerability.

GitHub Private Vulnerability Reporting must be enabled and the reporting link below must be tested before this repository is made public. Until that setting is enabled, OrbUX does not claim to offer a working confidential vulnerability intake and the public launch is blocked. The repository owner can enable it under Settings → Security → Code security and analysis → Private vulnerability reporting.

Use GitHub's private vulnerability reporting flow:

https://github.com/vikast908/ORBUX/security/advisories/new

If that form is unavailable after public launch, do not disclose exploit details through an issue, profile, discussion, or social post. The maintainer must restore private reporting or publish a monitored security address before accepting reports.

Include as much of the following as possible:

• affected package, loader, page, script, and commit or version
• vulnerability category and expected security boundary
• minimal reproduction or proof of concept
• realistic impact and required attacker capabilities
• affected browsers, operating systems, or package managers
• whether the issue is already public or being actively exploited
• a suggested remediation, if you have one
• how you would like to be credited

Reports without complete information are still welcome. Please keep destructive testing confined to systems and data you own or are authorized to test.

The maintainers aim to:

1. acknowledge a report within three business days
2. confirm whether it is in scope and reproduce it within seven business days
3. provide status updates at least every seven business days while remediation is active
4. coordinate a release and disclosure timeline with the reporter

These are response targets, not a service-level agreement. Complex issues or maintainer availability may require more time. If a report is declined, the response should explain why.

Examples of in-scope security issues include:

• cross-site scripting or unsafe dynamic HTML in the gallery or generated snippets
• path traversal or arbitrary file reads/writes in registry and catalog scripts
• malicious metadata escaping validation and reaching site output
• dependency or build-pipeline compromise with a plausible path to users
• package contents that differ materially from reviewed source
• prototype pollution, code execution, or unsafe evaluation in public APIs
• exposed credentials, tokens, signing material, or private user data
• denial-of-service behavior that can be triggered through ordinary public component input

Usually out of scope:

• visual defects, accessibility bugs, or performance concerns without a security impact
• attacks requiring a user to run arbitrary untrusted code in their own application
• vulnerabilities only in unsupported dependencies or browsers with no OrbUX-specific exposure
• missing headers on a local development server
• automated scan output without a reproducible exploit or affected code path
• social engineering, spam, and availability attacks against third-party infrastructure

When uncertain, report privately and let the maintainers assess it.

Please allow a reasonable remediation window before publishing details. The project will try to prepare a fix, tests, advisory, release notes, and package release together. Reporters who follow this policy may be credited in the advisory unless they request anonymity.

The project will not pursue action against good-faith research that follows this policy, avoids privacy violations and data destruction, and does not degrade services. This safe-harbor statement does not authorize testing of third-party systems.

For a confirmed vulnerability, maintainers should:

1. keep exploit details in a private GitHub security advisory
2. identify affected commits, releases, packages, and deployed artifacts
3. create a regression test before or alongside the fix when practical
4. review adjacent code paths for variants of the same flaw
5. rotate exposed credentials and invalidate affected artifacts when applicable
6. publish patched packages and deploy the corrected site
7. issue a GitHub Security Advisory with severity, impact, remediation, and credit
8. update this policy or the contribution process when the incident reveals a systemic gap

Security fixes may bypass the normal public review process until a patch is available.