Summary
WeGIA versions before 3.8.6 can reflect an attacker-supplied PHPSESSID value in a Set-Cookie response and reuse DB_HOST as the cookie domain. If a victim authenticates while using an attacker-selected session identifier, the attacker may reuse that identifier to access the victim's authenticated session, while the response can also disclose the internal database host name.
WeGIA versions before 3.8.6 can reflect an attacker-supplied PHPSESSID value in a Set-Cookie response and reuse DB_HOST as the cookie domain. If a victim authenticates while using an attacker-selected session identifier, the attacker may reuse that identifier to access the victim's authenticated session, while the response can also disclose the internal database host name.
Affected context
The issue occurs in WeGIA's session-start handling, which is automatically included across PHP pages. Risk is present when the application accepts a client-controlled session identifier, reflects it into session cookies, and derives the cookie Domain attribute from an internal database-host configuration value. Exploitation depends on a victim authenticating while the attacker-selected identifier remains in use.
The issue occurs in WeGIA's session-start handling, which is automatically included across PHP pages. Risk is present when the application accepts a client-controlled session identifier, reflects it into session cookies, and derives the cookie Domain attribute from an internal database-host configuration value. Exploitation depends on a victim authenticating while the attacker-selected identifier remains in use.
Exploit preconditions
- Attack surface: WeGIA web requests processed by the shared session-start handler
- Required access: Ability to cause a victim's browser to use or submit an attacker-selected PHP session identifier
- Trigger point: Victim authentication while the selected identifier is accepted and reflected by the application
- Why exploitation is possible: The session handling logic does not reliably replace or rotate the identifier at authentication, allowing the attacker to reuse the known identifier after login
- Additional exposure: The cookie Domain attribute may reveal the configured internal database host name
- Attack surface: WeGIA web requests processed by the shared session-start handler
- Required access: Ability to cause a victim's browser to use or submit an attacker-selected PHP session identifier
- Trigger point: Victim authentication while the selected identifier is accepted and reflected by the application
- Why exploitation is possible: The session handling logic does not reliably replace or rotate the identifier at authentication, allowing the attacker to reuse the known identifier after login
- Additional exposure: The cookie Domain attribute may reveal the configured internal database host name
Why this happens
The primary flaw is an authentication session-management failure mapped to CWE-384: Session Fixation, where a session identifier supplied before authentication remains valid after the user authenticates. The handler also reflects the identifier in a Set-Cookie response and uses an internal database-host value as cookie-domain data, creating a secondary CWE-200: Exposure of Sensitive Information condition. Together, these behaviors weaken session-boundary enforcement and disclose infrastructure details through HTTP response metadata.
The primary flaw is an authentication session-management failure mapped to CWE-384: Session Fixation, where a session identifier supplied before authentication remains valid after the user authenticates. The handler also reflects the identifier in a Set-Cookie response and uses an internal database-host value as cookie-domain data, creating a secondary CWE-200: Exposure of Sensitive Information condition. Together, these behaviors weaken session-boundary enforcement and disclose infrastructure details through HTTP response metadata.
Potential impact
- An attacker may access a victim's authenticated session
- Unauthorized actions may be performed with the victim's privileges
- Account data or institution records could be exposed or modified
- Session tokens may remain usable until expiration or invalidation
- The internal database host name may be disclosed
- Revealed infrastructure details could support further targeted attacks
- An attacker may access a victim's authenticated session
- Unauthorized actions may be performed with the victim's privileges
- Account data or institution records could be exposed or modified
- Session tokens may remain usable until expiration or invalidation
- The internal database host name may be disclosed
- Revealed infrastructure details could support further targeted attacks
General mitigation guidance
Mitigation generally focuses on enforcing server-side session lifecycle controls and separating internal configuration from client-visible cookie attributes.
Common defensive patterns include:
- Rotate or regenerate the session identifier whenever authentication state changes
- Reject attacker-supplied or otherwise untrusted session identifiers where appropriate
- Bind authenticated sessions to server-side state and invalidate pre-authentication sessions
- Set cookie attributes from explicit, trusted application configuration rather than database connection values
- Avoid exposing internal host names in response headers or other client-visible metadata
- Apply secure cookie attributes, appropriate expiration, and server-side logout invalidation
- Run application components with least privilege and limit the impact of a compromised session
Mitigation generally focuses on enforcing server-side session lifecycle controls and separating internal configuration from client-visible cookie attributes.
Common defensive patterns include:
- Rotate or regenerate the session identifier whenever authentication state changes
- Reject attacker-supplied or otherwise untrusted session identifiers where appropriate
- Bind authenticated sessions to server-side state and invalidate pre-authentication sessions
- Set cookie attributes from explicit, trusted application configuration rather than database connection values
- Avoid exposing internal host names in response headers or other client-visible metadata
- Apply secure cookie attributes, appropriate expiration, and server-side logout invalidation
- Run application components with least privilege and limit the impact of a compromised session
How teams detect issues like this
Organizations can assess this issue through:
- Dynamic tests that compare session identifiers before and after authentication
- Checks for session-cookie reflection and missing identifier rotation in login flows
- Static analysis and code review rules targeting direct use of request cookies in Set-Cookie responses
- Review of cookie Domain construction for references to database or internal infrastructure settings
- HTTP response monitoring for internal host names in cookie attributes
- Policy enforcement requiring secure session regeneration and approved cookie configuration
Automated application-security and code-review tools may help identify these patterns, but authentication-flow testing remains important.
Organizations can assess this issue through:
- Dynamic tests that compare session identifiers before and after authentication
- Checks for session-cookie reflection and missing identifier rotation in login flows
- Static analysis and code review rules targeting direct use of request cookies in Set-Cookie responses
- Review of cookie Domain construction for references to database or internal infrastructure settings
- HTTP response monitoring for internal host names in cookie attributes
- Policy enforcement requiring secure session regeneration and approved cookie configuration
Automated application-security and code-review tools may help identify these patterns, but authentication-flow testing remains important.
