https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 04 Nov 2026 22:08:56 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-82840 <p>Session fixation in Apache Wicket.</p> <p>org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket&#39;s role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim&#39;s browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason.</p> <p>AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session&#39;s signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen.</p> <p>An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requi…</p> <p>Session fixation in Apache Wicket.</p> <p>org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket&#39;s role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim&#39;s browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason.</p> <p>AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session&#39;s signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen.</p> <p>An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requi…</p> https://db.gcve.eu/vuln/fkie_cve-2026-82840 https://db.gcve.eu/vuln/ghsa-qqf3-jqrg-fm5r <p>Session fixation in Apache Wicket.</p> <p>org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket&#39;s role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim&#39;s browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason.</p> <p>AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session&#39;s signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen.</p> <p>An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requi…</p> <p>Session fixation in Apache Wicket.</p> <p>org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket&#39;s role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim&#39;s browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason.</p> <p>AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session&#39;s signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen.</p> <p>An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requi…</p> https://db.gcve.eu/vuln/ghsa-qqf3-jqrg-fm5r