A ZoomEye count-only query for title="ioBroker" returned 33,617 matches on November 10, 2026. The app="ioBroker" query returned 0. Both used page 1, pagesize 1 and sub_type=all.
The title may identify the Admin interface, a visualization, a documentation page or another web adapter. ioBroker is a Node.js automation platform with multiple adapters, so one URL can front several applications and permissions.
ioBroker uses internal users and groups, not operating-system accounts. Group permissions apply to objects, states, users, files and special operations. If a user is in several groups, the permissions combine. The stricter decision prevails only when both group and object ACLs are evaluated together.
The relevant question is which user the adapter assigns when authentication is absent or disabled.
Default-user behavior
The web adapter documentation says the authentication setting decides which user a request runs as. Without login, the adapter can use a default user. The access-control documentation warns that a web adapter without authentication can make everyone work as admin.
That is a configuration risk rather than a product-wide vulnerability. The outcome depends on the adapter instance and its settings. A title match might show a login page while another instance on the same host uses a default administrator.
For each web-facing adapter, review:
- 1.
Authentication enabled or disabled.
- 2.
Default user and its groups.
- 3.
Allowed user list.
- 4.
Object, state and file ACLs for each group.
- 5.
Special permissions for HTTP requests, scripts and administration.
Do not infer the default user from the URL. Verify it through an unauthenticated request and the adapter configuration.
Adapter boundaries
The web adapter serves files and applications through ioBroker. Visualization adapters, REST adapters and MCP servers may add their own authentication settings. One adapter can require login while another exposes the same objects through an API.
The administrator group is not the same as a group with every permission checked. The documentation says members of system.group.administrator pass every file check, while other users must pass the file ACL. That distinction matters when building a read-only operator account.
Review the object tree for devices, scripts and configuration. A state read may expose presence or energy data. A state write may control a physical device. A script edit can become arbitrary execution within the adapter's authority.
Respond to the count
The 33,617 title matches are a discovery signal, not proof that every instance is unauthenticated. The zero app count limits fingerprint certainty.
Use a small controlled test after confirming ownership:
- 1.
Request a protected page without a session.
- 2.
Record the effective user.
- 3.
Try a read that should require a non-default role.
- 4.
Try a write to an object with a restrictive ACL.
- 5.
Repeat through each reverse proxy and alternate port.
If an unauthenticated session runs as administrator, isolate the listener immediately. Enable authentication, assign the default user a restricted group and remove unnecessary file or object grants.
The ACL model is useful only when the session identity is correct. A strong object rule evaluated as admin grants admin behavior. The adapter setting is therefore part of the authorization boundary, not just a UI preference.