Summary
OpenBK7231T stores channel labels received through MQTT and later displays them in the device web panel without HTML encoding. An attacker who can publish to the relevant MQTT broker may inject script content that executes in the browser when a user views pages containing the affected label.
Affected context
The issue occurs in OpenBK7231T deployments where:
- Channel labels can be set through the MQTT
SetChannelLabelcommand - MQTT access is available to an attacker, including deployments with weak or absent broker authentication
- The web interface renders channel labels without context-appropriate HTML encoding
The risk is greatest when authenticated administrators or other privileged users view the affected device panel.
Exploit preconditions
- Attack surface: MQTT command handling and the device web interface
- Required access: Permission or ability to publish the channel-label command to the MQTT broker
- Trigger point: A user views a web-panel page that displays the modified channel label
- Why exploitation is possible: Label data is stored with
strdup()and returned without sanitization, then rendered throughhprintf255()without HTML encoding
Why this happens
The vulnerability is caused by treating MQTT-supplied channel labels as trusted display content. CHANNEL_SetLabel() stores attacker-controlled data, while CHANNEL_GetLabel() exposes it to multiple HTTP rendering paths without applying output encoding or enforcing a safe content policy.
This behavior maps to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). The insecure pattern is the insertion of untrusted data into HTML responses without context-aware escaping, allowing stored content to be interpreted as active browser markup or script.
Potential impact
- A malicious label may execute script in a user's browser
- An attacker could perform actions through the victim's authenticated web session
- Session information or sensitive interface data may be exposed, depending on browser and application controls
- Device settings could be altered through privileged browser interactions
- The web panel's integrity and trustworthiness could be undermined
General mitigation guidance
Mitigation generally focuses on treating all MQTT-provided labels as untrusted data and applying context-appropriate output encoding before rendering them in HTML.
Common defensive patterns include:
- Encoding labels at every HTML output sink rather than relying only on input filtering
- Applying strict validation for label length and permitted characters as a secondary control
- Using safe templating or response-generation APIs that encode dynamic values by default
- Separating data rendering from executable content and avoiding raw HTML insertion
- Restricting MQTT publishing rights and requiring strong broker authentication and authorization
- Applying least privilege to MQTT clients and web-panel users
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules identifying unescaped variables passed to HTML response functions
- Code review checks for MQTT, API, or configuration data flowing into web templates
- Searches for direct use of label values in
hprintf255()or comparable response-building functions - Tests that submit harmless marker strings containing HTML metacharacters and verify encoded output
- MQTT broker policy reviews covering anonymous publishing, topic permissions, and client isolation
Automated security review tools may help identify missing output encoding, but findings should be verified against the rendering context.
