Security FAQ
Page Guide
This page answers common questions about FastBee security remediation and upgrades. See Security Advisories for itemized status and evidence, and the Pre-deployment Security Checklist for launch verification.
1. Fixes and Versions
1.1. Are these vulnerabilities fixed in the new version?
The maintained codebase includes the corresponding fixes, but that does not prove every installation package contains them. CVE-2026-120274 has public fix commit 890a33846005a937a58cccd738b7fb9821b82ea9; other items should also be checked against the advisory. When the first official release containing each fix is still pending verification, check deployed code, configuration, and regression results together.
1.2. How can I tell whether my instance is affected?
Record the actual version and deployment method, then inspect relevant source code, APIs, role permissions, and exposed ports. Device-group IDOR requires ownership checks, Groovy requires compile-time and runtime controls, and SIP XXE requires parser configuration. Do not rely on a version label or third-party reproduction article alone.
1.3. Is updating to the latest code enough to be secure?
No. Maintained-code fixes do not replace instance verification. Public deployments also require default-password rotation, demo-permission restrictions, SIP exposure controls, download authorization, and self-registration review. Positive and negative verification is required after upgrading.
2. Upgrades and Account Handling
2.1. What is the recommended upgrade order?
Identify the current and target versions, schedule a maintenance window, and back up the database and deployment packages. Read the release notes, run upgrade SQL in version order, replace backend jars and frontend assets, then start and validate the system. Do not skip SQL versions or replace only one side.
2.2. How do I obtain fixes with an expired commercial subscription or custom development?
Do not overwrite production code directly. Merge the target fixes in an isolated branch or test environment, separate official changes from local business changes, and resolve conflicts in code, database scripts, configuration, and frontend dependencies. Then regression-test custom protocols, permissions, pages, and business flows.
2.3. Must default accounts be removed or forcibly changed?
Default credentials are intended for initial deployment, and users can change them afterward; the existing deployment flow is unchanged. Public and production instances should rotate default passwords and restrict demo-account permissions before launch to reduce unsolicited login attempts.
3. Specialized Verification
3.1. How do I verify the device-group IDOR fix?
Use accounts with different owners to test device-group read, update, reassignment, device-association changes, and deletion. Cross-user operations must be denied and logged, while owner operations still work. Controller, service, and Mapper layers must not be checked in isolation.
3.2. Is hiding the script editor enough to fix Groovy injection?
No. Verify both compile-time restrictions in SecureGroovyScriptExecutor.compileSource and runtime restrictions in BusinessScriptInterceptor, and confirm that persistence and hot-loading apply the same validation. Hiding the editor or removing import is not a substitute for sandboxing and authorization.
3.3. Which security logs should I review after upgrading?
Review login and access logs, authorization denials, unexpected device-group changes, script changes and abnormal execution, SIP logs, and abnormal outbound connections. Logs support detection but do not replace negative authorization tests.
4. Reporting and Support
4.1. How do I report a new security issue?
Email 164770707@qq.com with the subject "FastBee Security Issue". Include the installed version, affected product, reproduction steps, impact, and relevant logs. For undisclosed issues, do not publish vulnerability details or exploitable PoCs in public Issues first.