Pre-deployment Security Checklist

Page Guide

Use this checklist before deploying FastBee Open Source, Commercial, or Cluster Edition to a public or production environment. The maintained codebase includes the corresponding fixes, but instance safety still depends on deployed code, configuration, and permissions. Items whose first official release is pending verification are identified in the Security Advisories.

Default credentials are intended for initial deployment, and users can change them after deployment; the existing deployment flow is unchanged. Public and production instances should complete credential and permission checks before becoming externally accessible.

1. Six Pre-launch Requirements

• [ ] Rotate default passwords: the platform admin, MySQL, Redis, and EMQX console must not retain default or weak passwords. Any successful default login is a failure.
• [ ] Disable or secure the go-view direct SQL endpoint: disable GoviewProjectDataController#executeSql when unused; otherwise require authentication and authorization. Executing SQL anonymously is a failure.
• [ ] Restrict demo-account permissions: demo roles must not have monitor:cache:list; on Commercial V2.7.0 and later, the fastbee guest role uses self-only data scope.
• [ ] Restrict SIP exposure: when SIP video access is unused, close and restrict 5060/5061 and remove demo devices and default credentials.
• [ ] Disable unneeded self-registration: reduce sources of low-privilege accounts. If registration is required, complete permission and audit verification first.
• [ ] Authenticate downloads and retain logs: disable unneeded endpoints at both gateway and application layers. Remaining endpoints require authentication, authorization, and access logs.

2. Item-by-item Verification

2.1. Default passwords and initial accounts

• Where to check: initial configuration, component consoles, and initial accounts in deployment guides.
• Pass condition: initial accounts are used only for first-time setup, and public or production instances use strong, unique passwords.
• Remediation: users rotate credentials themselves; the official default deployment flow remains unchanged.
• Regression: new credentials work, old defaults fail, and component connections remain healthy.

2.2. Demo-account logic flaw

• Where to check: role management and the permission tree of roles assigned to demo accounts.
• Pass condition: demo roles do not have monitor:cache:list, cannot read other users' login information, and use the data scope required by the current version.
• Remediation: remove cache-monitoring permission and set guest-role data scope to self only.
• Regression: demo accounts cannot access cache lists or other users' data, while permitted demo functions still work.

2.3. go-view arbitrary SQL execution

• Where to check: executeSql in com.fastbee.controller.goview.GoviewProjectDataController.
• Pass condition: unauthenticated calls cannot execute SQL, and authorized users can perform only operations within their permissions.
• Remediation: remove or disable the endpoint when unused; otherwise add authentication and authorization.
• Regression: anonymous requests are rejected and normal dashboard queries continue to work.

2.4. Stored XSS

• Where to check: news, notices, and device-log write and rich-text rendering paths.
• Pass condition: DOMPurify and backend jsoup allowlists are active in the current implementation. Dangerous tags, event attributes, script protocols, and iframes are removed while safe link attributes are preserved.
• Remediation: synchronize frontend sanitization, backend RichTextSanitizer, and the corresponding unit tests from maintained code rather than relying on a blacklist.
• Regression: test markup submitted in an isolated environment does not execute, and legitimate rich text and device logs still render correctly.

2.5. SIP XML External Entity (CVE-2025-15251)

• Where to check: ReqAbstractHandler#getRootElement and SIP network configuration.
• Pass condition: the parser disables DTD, external general entities, and external parameter entities; SIP is not exposed to untrusted networks.
• Remediation: set disallow-doctype-decl=true, external-general-entities=false, and external-parameter-entities=false, and restrict 5060/5061.
• Regression: external DTD and entity requests are rejected while normal SIP operations continue. A JDK upgrade alone is not verification.

2.6. Arbitrary File Read via Download Endpoint (CVE-2026-7676)

• Where to check: fileName handling in ToolController.download.
• Pass condition: the normalized target stays inside the allowed download directory; absolute paths, traversal, and symlink escapes are rejected; the endpoint requires authorization and logging.
• Remediation: use normalized absolute paths with directory-boundary checks rather than string replacement alone. Disable unneeded gateway and application entry points.
• Regression: paths outside an isolated test directory are unreadable and normal files still download.

2.7. Device-group IDOR (CVE-2026-111654)

• Where to check: GroupController and downstream service and Mapper query paths.
• Pass condition: read, update, reassignment, device-association changes, and deletion all verify device-group ownership or tenant boundaries.
• Remediation: enforce consistent authorization across controller, service, and data-access layers; hiding frontend buttons or checking only that a group ID exists is insufficient.
• Regression: use accounts with different owners to confirm cross-user operations are denied and logged while owner operations still work.

2.8. Groovy Rule-script Injection (CVE-2026-120274)

• Where to check: /iot/script create/edit paths, Groovy executor assembly, and persistence and hot-loading paths.
• Pass condition: both SecureGroovyScriptExecutor.compileSource and BusinessScriptInterceptor are active. Compile-time checks reject classes, packages, annotations, and custom constructors; runtime controls deny process, file, and reflection calls by default.
• Remediation: deploy the implementation containing fix commit 890a33846005a937a58cccd738b7fb9821b82ea9, and require the same compiler validation before persistence and hot-loading.
• Regression: dangerous structures are rejected, valid scripts still run, and standard-privilege accounts cannot edit scripts. Removing import or hiding the editor is not a fix.

2.9. Vertical Privilege Escalation and Data Scope

• Where to check: permission annotations and data-scope validation in system user, role, post, and department APIs.
• Pass condition: administrator API calls from low-privilege accounts return 403, non-superusers cannot read superuser data, and lists are restricted to the current user's data scope.
• Remediation: synchronize permission annotations, checkDeptDataScope / checkUserDataScope, and exception handling; do not rely on hidden menus.
• Regression: test a matrix of owners, departments, roles, and permission levels, confirming unauthorized actions are denied and authorized operations still work.

3. Unified Pre-launch Regression

• [ ] Back up programs, configuration, and data before remediation, and validate compatibility in an isolated test environment.
• [ ] Run positive and negative checks for every item: dangerous actions are denied and normal business behavior still works.
• [ ] Use at least two accounts with different owners and permission levels rather than testing only as admin.
• [ ] Verify access logs, authorization-denial logs, SIP logs, and abnormal outbound connections are observable.
• [ ] When a commercial subscription has expired or custom development exists, merge the target fixes and resolve conflicts in a test branch before touching production.
• [ ] Run upgrade SQL in version order, and clear only the documented caches or adjust time-series schemas as required by the target release.

4. Frequently Asked Questions

Do I still need this checklist when the maintained code is fixed?

Yes. A fix in maintained code does not prove that an instance was upgraded or that passwords, exposed ports, and role permissions are safe. The checklist verifies the actual deployment.

Must default accounts be deleted?

No. Default credentials are intended for initial deployment, and users can change them afterward. Public and production instances should rotate passwords and restrict demo permissions before launch.

Can I run exploit PoCs in production to verify fixes?

No. Use isolated test environments with non-sensitive test data and negative authorization checks to avoid affecting business operations and data.