CVE-2026-39355
Broken Access Control in Genealogy PHP Allows Team Takeover
Publication date: 2026-04-07
Last updated on: 2026-04-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| kreaweb | genealogy | to 5.9.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-862 | The product does not perform an authorization check when an actor attempts to access a resource or perform an action. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows any authenticated user to take over ownership of arbitrary non-personal teams, gaining unrestricted access to all genealogy data associated with those teams. Such unauthorized access and potential data modification or deletion could lead to violations of data protection regulations that require strict access controls and data integrity, such as GDPR and HIPAA.
Because the vulnerability results in a complete takeover of team workspaces and associated data without proper authorization, it undermines confidentiality, integrity, and availability of data, which are core principles in many compliance frameworks.
Therefore, if exploited, this vulnerability could cause non-compliance with standards that mandate secure access controls and protection of sensitive data.
Can you explain this vulnerability to me?
CVE-2026-39355 is a critical broken access control vulnerability in the genealogy PHP application prior to version 5.9.1.
The flaw exists in the TeamController::transferOwnership() method, which allows any authenticated user to transfer ownership of arbitrary non-personal teams to themselves without proper authorization checks.
Specifically, the application only checks if the new owner user exists but does not verify if the requester is the current owner or a member of the team, nor if the new owner is a team member.
This means an attacker with any authenticated account can hijack ownership of teams they do not belong to, gaining full control over those team workspaces.
How can this vulnerability impact me? :
This vulnerability allows an attacker with any authenticated account to take over ownership of any team they do not own or belong to.
- Complete takeover of other users’ team workspaces.
- Unrestricted access to all genealogy data associated with the compromised team.
- Ability to modify or delete data, demote legitimate owners, and cause permanent data loss.
- Unauthorized reassignment of team ownership.
No special privileges or prior membership are required beyond having a valid authenticated account and knowledge of a target team identifier.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unauthorized HTTP requests to the team ownership transfer endpoint, which is handled by the `TeamController::transferOwnership()` method in the genealogy application.
Since the vulnerability allows any authenticated user to transfer ownership of arbitrary non-personal teams by sending a request with a `new_owner_id` parameter without proper authorization checks, detection involves identifying suspicious POST or PUT requests to this endpoint that change team ownership.
Suggested commands to detect exploitation attempts include inspecting web server logs or using network monitoring tools to filter requests targeting the ownership transfer functionality. For example, using grep on access logs to find requests containing `new_owner_id` or targeting the relevant URL path.
- grep 'new_owner_id' /var/log/nginx/access.log
- grep 'transferOwnership' /var/log/apache2/access.log
- Use a network packet capture tool like tcpdump or Wireshark to filter HTTP POST requests to the team ownership transfer endpoint.
- Review application logs for unexpected changes in team ownership or audit logs if available.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the genealogy application to version 5.9.1 or later, where the vulnerability is fixed by enforcing proper authorization checks.
Until the upgrade can be applied, restrict access to the vulnerable endpoint by implementing network-level controls such as firewall rules or web application firewall (WAF) rules to block unauthorized requests to the ownership transfer functionality.
Additionally, monitor logs for suspicious ownership transfer attempts and revoke or reset any unauthorized ownership changes detected.