Feng Office: a small title sample with a broad document-permission question
Feng Office is a collaboration and document-management platform. Its data model includes companies, users, groups, projects, documents, contacts, and administrative settings. A public deployment may show only a login page, but the account behind that page can expose files and business records across an organization.
ZoomEye count-only measurements on 2026-11-09 between 23:46 and 23:47 UTC returned 12 assets for title="Feng Office", 325 for the product name in the HTTP body, and zero for app="Feng Office". The query used sub_type=all, page 1, and page size 1. This is a small title sample, so aggregate statements about a market or a vulnerability population are not justified.
The body count is larger because the name can appear in documentation, support pages, and portals. It is not a list of 325 active Feng Office installations. The title count is a more specific discovery signal, but a title match still needs confirmation from an authorized session. The zero app count reinforces the need for manual identity checks.
The permission model
Feng Office's documentation describes users, groups that act as roles, and a super administrator with broad control. The owner company is special: every user who belongs to it is a potential administrator of the installation. Groups grant permission sets, and a user can receive permissions directly or through a group.
That design creates several review questions. Is the owner company limited to the right people? Can a client company administrator see another client's documents? Does a user with security-management permission have the ability to broaden their own role? Are document folders, project permissions, and contact visibility managed as one boundary or as separate settings that can drift?
The official documentation also describes a backup function that can create a ZIP containing the database and files. An account with that authority has a concentration of data and secrets. It belongs in the privileged-access review, not in a general staff-user group.
Measurement method
The SDK requested one record per dork with sub_type="all", page 1, and page size 1. The title, body, and application counts are exact matched totals. No full asset records or credentials were retrieved. The public search link uses the title query because it is the most specific positive signal in this sample.
An authorized reviewer can confirm the application by opening the title result, checking the login path, and comparing the page with the documented administration interface. Do not treat a body match as proof that the host is a Feng Office server.
A review sequence
Start with the owner company and super administrators. Confirm that the list is current and that every account has a named owner. Remove former employees and contractor accounts, then review direct permissions as well as group membership.
Review client and company boundaries. Create a test user in one client company and attempt to read a document, contact, and project that belongs to another. Test the UI and the API or export path if one is available. The result should match the documented permission model, not only the menu configuration.
Check document storage and backup access. Only a small set of administrators should be able to download a full installation backup. Store backups in a separate protected location and rotate any database or storage credentials included in the backup.
Finally, examine the reverse proxy and session settings. A public login page should use HTTPS, secure cookies, and a deliberate password or SSO policy. Restrict the administrative path where the deployment supports it, but do not rely on a hidden URL as the only control.
What the small sample means
Twelve title matches do not support a claim about the total Feng Office population or about the number of exposed documents. They do support a targeted observation: the product name is visible in public data, and the control plane deserves a permission review when an organization finds one of its own instances.
The body count should be described as a candidate set. The zero application fingerprint is a limitation of the index, not a clean bill of health. A responsible inventory uses all three signals, prioritizes the title matches, and reports the remaining uncertainty.
Top comments (0)