hitoshura25/cvefixes huggingface dataset:
CVE-2019-10909 (PHP, published 2019-05-16T22:29Z)
Description: value: In Symfony before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, validation messages are not escaped, which can lead to XSS when user input is included. This is related to symfony/framework-bundle.
Severity: LOW (CVSS v3 base score: 5.4)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Bundle/FrameworkBundle/Resources/views/Form/choice_widget_collapsed.html.php
src/Symfony/Bundle/FrameworkBundle/Resources/views/Form/form_errors.html.php
src/Symfony/Bundle/FrameworkBundle/Resources/views/Form/form_start.html.php
Commit message: Fix XSS issues in the form theme of the PHP templating engine


Vulnerable code:
            <option disabled="disabled"><?php echo $separator ?></option>
            <li><?php echo $error->getMessage() ?></li>
<form name="<?php echo $name ?>" method="<?php echo strtolower($form_method) ?>"<?php if ($action !== ''): ?> action="<?php echo $action ?>"<?php endif ?><?php foreach ($attr as $k => $v) { printf(' %s="%s"', $view->escape($k), $view->escape($v)); } ?><?php if ($multipart): ?> enctype="multipart/form-data"<?php endif ?>>
    <input type="hidden" name="_method" value="<?php echo $method ?>" />

Fixed code:
            <option disabled="disabled"><?php echo $view->escape($separator) ?></option>
            <li><?php echo $view->escape($error->getMessage()) ?></li>
<form name="<?php echo $name ?>" method="<?php echo strtolower($form_method) ?>"<?php if ($action !== ''): ?> action="<?php echo $view->escape($action) ?>"<?php endif ?><?php foreach ($attr as $k => $v) { printf(' %s="%s"', $view->escape($k), $view->escape($v)); } ?><?php if ($multipart): ?> enctype="multipart/form-data"<?php endif ?>>
    <input type="hidden" name="_method" value="<?php echo $view->escape($method) ?>" />
CVE-2019-10911 (PHP, published 2019-05-16T22:29Z)
Description: value: In Symfony before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, a vulnerability would allow an attacker to authenticate as a privileged user on sites with user registration and remember me login functionality enabled. This is related to symfony/security.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-287 \u2014 Improper Authentication
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Component/Security/Http/RememberMe/TokenBasedRememberMeServices.php
Commit message: [Security] Add a separator in the remember me cookie hash


Vulnerable code:
        return hash_hmac('sha256', $class.$username.$expires.$password, $this->getSecret());

Fixed code:
        return hash_hmac('sha256', $class.self::COOKIE_DELIMITER.$username.self::COOKIE_DELIMITER.$expires.self::COOKIE_DELIMITER.$password, $this->getSecret());
CVE-2019-10912 (PHP, published 2019-05-16T22:29Z)
Description: value: In Symfony before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, it is possible to cache objects that may contain bad user input. On serialization or unserialization, this could result in the deletion of files that the current user has access to. This is related to symfony/cache and symfony/phpunit-bridge.
Severity: MEDIUM (CVSS v3 base score: 7.1)
Weakness: CWE-502 \u2014 Deserialization of Untrusted Data
The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Bridge/PhpUnit/Legacy/SymfonyTestsListenerTrait.php
src/Symfony/Bundle/FrameworkBundle/Tests/Kernel/ConcreteMicroKernel.php
src/Symfony/Component/Cache/Traits/FilesystemCommonTrait.php
Commit message: Prevent destructors with side-effects from being unserialized


Vulnerable code:

Fixed code:
    public function __sleep()
    {
        throw new \BadMethodCallException('Cannot serialize '.__CLASS__);
    }

    public function __wakeup()
    {
        throw new \BadMethodCallException('Cannot unserialize '.__CLASS__);
    }

    public function __sleep()
    {
        throw new \BadMethodCallException('Cannot serialize '.__CLASS__);
    }

    public function __wakeup()
    {
        throw new \BadMethodCallException('Cannot unserialize '.__CLASS__);
    }

    public function __sleep()
    {
        throw new \BadMethodCallException('Cannot serialize '.__CLASS__);
    }

    public function __wakeup()
    {
        throw new \BadMethodCallException('Cannot unserialize '.__CLASS__);
    }
CVE-2019-10913 (PHP, published 2019-05-16T22:29Z)
Description: value: In Symfony before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, HTTP Methods provided as verbs or using the override header may be treated as trusted input, but they are not validated, possibly causing SQL injection or XSS. This is related to symfony/http-foundation.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Component/HttpFoundation/Request.php
Commit message: [HttpFoundation] reject invalid method override


Vulnerable code:
        if (null === $this->method) {
            $this->method = strtoupper($this->server->get('REQUEST_METHOD', 'GET'));

            if ('POST' === $this->method) {
                if ($method = $this->headers->get('X-HTTP-METHOD-OVERRIDE')) {
                    $this->method = strtoupper($method);
                } elseif (self::$httpMethodParameterOverride) {
                    $method = $this->request->get('_method', $this->query->get('_method', 'POST'));
                    if (\is_string($method)) {
                        $this->method = strtoupper($method);
                    }
                }
            }
        return $this->method;

Fixed code:
        if (null !== $this->method) {
            return $this->method;
        }

        $this->method = strtoupper($this->server->get('REQUEST_METHOD', 'GET'));

        if ('POST' !== $this->method) {
            return $this->method;
        }

        $method = $this->headers->get('X-HTTP-METHOD-OVERRIDE');

        if (!$method && self::$httpMethodParameterOverride) {
            $method = $this->request->get('_method', $this->query->get('_method', 'POST'));
        }

        if (!\is_string($method)) {
            return $this->method;
        }

        $method = strtoupper($method);

        if (\in_array($method, ['GET', 'HEAD', 'POST', 'PUT', 'DELETE', 'CONNECT', 'OPTIONS', 'PATCH', 'PURGE', 'TRACE'], true)) {
            return $this->method = $method;
        }

        if (!preg_match('/^[A-Z]++$/D', $method)) {
            throw new SuspiciousOperationException(sprintf('Invalid method override "%s".', $method));
        return $this->method = $method;
CVE-2019-10913 (PHP, published 2019-05-16T22:29Z)
Description: value: In Symfony before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, HTTP Methods provided as verbs or using the override header may be treated as trusted input, but they are not validated, possibly causing SQL injection or XSS. This is related to symfony/http-foundation.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-89 \u2014 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Component/HttpFoundation/Request.php
Commit message: [HttpFoundation] reject invalid method override


Vulnerable code:
        if (null === $this->method) {
            $this->method = strtoupper($this->server->get('REQUEST_METHOD', 'GET'));

            if ('POST' === $this->method) {
                if ($method = $this->headers->get('X-HTTP-METHOD-OVERRIDE')) {
                    $this->method = strtoupper($method);
                } elseif (self::$httpMethodParameterOverride) {
                    $method = $this->request->get('_method', $this->query->get('_method', 'POST'));
                    if (\is_string($method)) {
                        $this->method = strtoupper($method);
                    }
                }
            }
        return $this->method;

Fixed code:
        if (null !== $this->method) {
            return $this->method;
        }

        $this->method = strtoupper($this->server->get('REQUEST_METHOD', 'GET'));

        if ('POST' !== $this->method) {
            return $this->method;
        }

        $method = $this->headers->get('X-HTTP-METHOD-OVERRIDE');

        if (!$method && self::$httpMethodParameterOverride) {
            $method = $this->request->get('_method', $this->query->get('_method', 'POST'));
        }

        if (!\is_string($method)) {
            return $this->method;
        }

        $method = strtoupper($method);

        if (\in_array($method, ['GET', 'HEAD', 'POST', 'PUT', 'DELETE', 'CONNECT', 'OPTIONS', 'PATCH', 'PURGE', 'TRACE'], true)) {
            return $this->method = $method;
        }

        if (!preg_match('/^[A-Z]++$/D', $method)) {
            throw new SuspiciousOperationException(sprintf('Invalid method override "%s".', $method));
        return $this->method = $method;
CVE-2020-15094 (Unknown, published 2020-09-02T18:15Z)
Description: value: In Symfony before versions 4.4.13 and 5.1.5, the CachingHttpClient class from the HttpClient Symfony component relies on the HttpCache class to handle requests. HttpCache uses internal headers like X-Body-Eval and X-Body-File to control the restoration of cached responses. The class was initially written with surrogate caching and ESI support in mind (all HTTP calls come from a trusted backend in that scenario). But when used by CachingHttpClient and if an attacker can control the response for a request being made by the CachingHttpClient, remote code execution is possible. This has been fixed in versions 4.4.13 and 5.1.5.
Severity: HIGH (CVSS v3 base score: 8.8)
Weakness: CWE-212 \u2014 Improper Removal of Sensitive Information Before Storage or Transfer
The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
Repository: https://github.com/symfony/symfony
Files changed:
Commit message: security #cve-2020-15094 Remove headers with internal meaning from HttpClient responses (mpdude)

This PR was merged into the 4.4 branch.


Vulnerable code:

Fixed code:
CVE-2020-5255 (Unknown, published 2020-03-30T20:15Z)
Description: value: In Symfony before versions 4.4.7 and 5.0.7, when a `Response` does not contain a `Content-Type` header, affected versions of Symfony can fallback to the format defined in the `Accept` header of the request, leading to a possible mismatch between the response&#39;s content and `Content-Type` header. When the response is cached, this can prevent the use of the website by other users. This has been patched in versions 4.4.7 and 5.0.7.
Severity: MEDIUM (CVSS v3 base score: 4.3)
Weakness: CWE-20 \u2014 Improper Input Validation
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.
Repository: https://github.com/symfony/symfony
Files changed:
Commit message: security #cve-2020-5255 [HttpFoundation] Do not set the default Content-Type based on the Accept header (yceruto)

This PR was merged into the 4.4 branch.


Vulnerable code:

Fixed code:
CVE-2020-5274 (PHP, published 2020-03-30T20:15Z)
Description: value: In Symfony before versions 5.0.5 and 4.4.5, some properties of the Exception were not properly escaped when the `ErrorHandler` rendered it stacktrace. In addition, the stacktrace were displayed even in a non-debug configuration. The ErrorHandler now escape alls properties of the exception, and the stacktrace is only display in debug configuration. This issue is patched in symfony/http-foundation versions 4.4.5 and 5.0.5
Severity: MEDIUM (CVSS v3 base score: 5.4)
Weakness: CWE-209 \u2014 Generation of Error Message Containing Sensitive Information
The product generates an error message that includes sensitive information about its environment, users, or associated data.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Component/ErrorHandler/Resources/views/traces_text.html.php
Commit message: Escape variable in Exception Template


Vulnerable code:
                    echo $exception['class'].":\n";
                        echo $exception['message']."\n";
                            echo 'at '.$trace['class'].$trace['type'].$trace['function'].'('.(isset($trace['args']) ? $this->formatArgsAsText($trace['args']) : '').')';

Fixed code:
                    echo $this->escape($exception['class']).":\n";
                        echo $this->escape($exception['message'])."\n";
                            echo $this->escape('at '.$trace['class'].$trace['type'].$trace['function']).'('.(isset($trace['args']) ? $this->formatArgsAsText($trace['args']) : '').')';
CVE-2020-5274 (PHP, published 2020-03-30T20:15Z)
Description: value: In Symfony before versions 5.0.5 and 4.4.5, some properties of the Exception were not properly escaped when the `ErrorHandler` rendered it stacktrace. In addition, the stacktrace were displayed even in a non-debug configuration. The ErrorHandler now escape alls properties of the exception, and the stacktrace is only display in debug configuration. This issue is patched in symfony/http-foundation versions 4.4.5 and 5.0.5
Severity: MEDIUM (CVSS v3 base score: 5.4)
Weakness: CWE-209 \u2014 Generation of Error Message Containing Sensitive Information
The product generates an error message that includes sensitive information about its environment, users, or associated data.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Component/ErrorHandler/Debug.php
src/Symfony/Component/ErrorHandler/ErrorHandler.php
Commit message: Added debug argument to decide if debug page should be shown or not


Vulnerable code:
        return ErrorHandler::register(new ErrorHandler(new BufferingLogger()));
    public function __construct(BufferingLogger $bootstrappingLogger = null)
        $renderer = \in_array(\PHP_SAPI, ['cli', 'phpdbg'], true) ? new CliErrorRenderer() : new HtmlErrorRenderer(0 !== $this->scopedErrors);

Fixed code:
        return ErrorHandler::register(new ErrorHandler(new BufferingLogger(), true));
    private $debug;
    public function __construct(BufferingLogger $bootstrappingLogger = null, bool $debug = false)
        $this->debug = $debug;
        $renderer = \in_array(\PHP_SAPI, ['cli', 'phpdbg'], true) ? new CliErrorRenderer() : new HtmlErrorRenderer($this->debug);
CVE-2020-5275 (Unknown, published 2020-03-30T20:15Z)
Description: value: In symfony/security-http before versions 4.4.7 and 5.0.7, when a `Firewall` checks access control rule, it iterate overs each rule's attributes and stops as soon as the accessDecisionManager decides to grant access on the attribute, preventing the check of next attributes that should have been take into account in an unanimous strategy. The accessDecisionManager is now called with all attributes at once, allowing the unanimous strategy being applied on each attribute. This issue is patched in versions 4.4.7 and 5.0.7.
Severity: MEDIUM (CVSS v3 base score: 8.1)
Weakness: CWE-863 \u2014 Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.
Repository: https://github.com/symfony/symfony
Files changed:
Commit message: security #cve-2020-5275 [Security] Fix access_control behavior with unanimous decision strategy (chalasr)

This PR was merged into the 4.4 branch.


Vulnerable code:

Fixed code:
CVE-2021-21424 (Unknown, published 2021-05-13T16:15Z)
Description: value: Symfony is a PHP framework for web and console applications and a set of reusable PHP components. The ability to enumerate users was possible without relevant permissions due to different handling depending on whether the user existed or not when attempting to use the switch users functionality. We now ensure that 403s are returned whether the user exists or not if a user cannot switch to a user or if the user does not exist. The patch for this issue is available for branch 3.4.
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/symfony/symfony
Files changed:
Commit message: security #cve-2021-21424 [Security][Guard] Prevent user enumeration (chalasr)

This PR was merged into the 3.4 branch.


Vulnerable code:

Fixed code:
CVE-2021-41267 (PHP, published 2021-11-24T19:15Z)
Description: value: Symfony/Http-Kernel is the HTTP kernel component for Symfony, a PHP framework for web and console applications and a set of reusable PHP components. Headers that are not part of the "trusted_headers" allowed list are ignored and protect users from "Cache poisoning" attacks. In Symfony 5.2, maintainers added support for the `X-Forwarded-Prefix` headers, but this header was accessible in SubRequest, even if it was not part of the "trusted_headers" allowed list. An attacker could leverage this opportunity to forge requests containing a `X-Forwarded-Prefix` header, leading to a web cache poisoning issue. Versions 5.3.12 and later have a patch to ensure that the `X-Forwarded-Prefix` header is not forwarded to subrequests when it is not trusted.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-444 \u2014 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
The product acts as an intermediary HTTP agent
         (such as a proxy or firewall) in the data flow between two
         entities such as a client and server, but it does not
         interpret malformed HTTP requests or responses in ways that
         are consistent with how the messages will be processed by
         those entities that are at the ultimate destination.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Component/HttpKernel/HttpCache/SubRequestHandler.php
src/Symfony/Component/HttpKernel/Tests/HttpCache/SubRequestHandlerTest.php
Commit message: Fix missing extra trusted header in sub-request


Vulnerable code:

Fixed code:
                'X_FORWARDED_PREFIX' => $trustedHeaderSet & Request::HEADER_X_FORWARDED_PREFIX,
        $request->headers->set('X-Forwarded-Prefix', '/admin');
            $this->assertSame('/admin', $request->headers->get('X-Forwarded-Prefix'));
        $request->headers->set('X-Forwarded-Prefix', '/admin');
            $this->assertFalse($request->headers->has('X-Forwarded-Prefix'));
        $request->headers->set('X-Forwarded-Prefix', '/admin');
            $this->assertSame('/admin', $request->getBaseUrl());
CVE-2022-24894 (PHP, published 2023-02-03T22:15Z)
Description: value: Symfony is a PHP framework for web and console applications and a set of reusable PHP components. The Symfony HTTP cache system, acts as a reverse proxy: It caches entire responses (including headers) and returns them to the clients. In a recent change in the `AbstractSessionListener`, the response might contain a `Set-Cookie` header. If the Symfony HTTP cache system is enabled, this response might bill stored and return to the next clients. An attacker can use this vulnerability to retrieve the victim's session. This issue has been patched and is available for branch 4.4.

Severity: nan (CVSS v3 base score: 8.8)
Weakness: CWE-285 \u2014 Improper Authorization
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
Repository: https://github.com/symfony/symfony
Files changed:
src/Symfony/Component/HttpKernel/HttpCache/Store.php
src/Symfony/Component/HttpKernel/Tests/HttpCache/StoreTest.php
Commit message: [HttpKernel] Remove private headers before storing responses with HttpCache


Vulnerable code:
    private $locks;
    public function __construct(string $root)
        $this->locks = [];

Fixed code:
    private $locks = [];
    private $options;
     * Constructor.
     *
     * The available options are:
     *
     *   * private_headers  Set of response headers that should not be stored
     *                      when a response is cached. (default: Set-Cookie)
     *
    public function __construct(string $root, array $options = [])
        $this->options = array_merge([
            'private_headers' => ['Set-Cookie'],
        ], $options);
        foreach ($this->options['private_headers'] as $h) {
            unset($headers[strtolower($h)]);
        }

use Symfony\Component\HttpFoundation\Cookie;
use Symfony\Component\HttpKernel\HttpCache\HttpCache;
    public function testDoesNotStorePrivateHeaders()
    {
        $request = Request::create('https://example.com/foo');
        $response = new Response('foo');
        $response->headers->setCookie(Cookie::fromString('foo=bar'));

        $this->store->write($request, $response);
        $this->assertArrayNotHasKey('set-cookie', $this->getStoreMetadata($request)[0][1]);
        $this->assertNotEmpty($response->headers->getCookies());
    }
CVE-2023-46733 (Unknown, published 2023-11-10T18:15Z)
Description: value: Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Starting in versions 5.4.21 and 6.2.7 and prior to versions 5.4.31 and 6.3.8, `SessionStrategyListener` does not migrate the session after every successful login. It does so only in case the logged in user changes by means of checking the user identifier. In some use cases, the user identifier doesn't change between the verification phase and the successful login, while the token itself changes from one type (partially-authenticated) to another (fully-authenticated). When this happens, the session id should be regenerated to prevent possible session fixations, which is not the case at the moment. As of versions 5.4.31 and 6.3.8, Symfony now checks the type of the token in addition to the user identifier before deciding whether the session id should be regenerated.
Severity: nan (CVSS v3 base score: 6.5)
Weakness: CWE-384 \u2014 Session Fixation
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
Repository: https://github.com/symfony/symfony
Files changed:
Commit message: security #cve-2023-46733 [Security] Fix possible session fixation when only the *token* changes (RobertMe)

This PR was merged into the 5.4 branch.


Vulnerable code:

Fixed code: