vulnerability / NVI-00005164 / Revision 4
Ability to switch customer email address on account detail page and stay verified
OSV carries this publisher advisory for sylius/sylius, sylius/sylius, sylius/sylius. This is an aggregated source copy; consult the original publisher and compare update dates.
This report has not inspected your inventory, configuration, deployed build, reachability or evidence. A catalog listing and a severity score do not establish exposure or compromise.
01 / Meaning
Why it matters
Published affected context helps an owner decide what evidence to gather. This report has not examined your application.
4 MEDIUM (2.0)
nvd@nist.gov severity; no combined Null risk score.
4.3 MEDIUM (3.1)
security-advisories@github.com severity; no combined Null risk score.
4.3 MEDIUM (3.1)
nvd@nist.gov severity; no combined Null risk score.
0.627%
FIRST EPSS model v2026.06.15; exploitation probability over 30 days, percentile 0.50074. Missing scores are unknown.
As of · FIRST EPSS
02 / Applicability
The affected context
Affected versions, configuration prerequisites and known exclusions are public. Confirm each one against the deployed service.
sylius/sylius
source listedECOSYSTEM: introduced 1.7.0; fixed 1.7.9
### Impact The user may register in a shop by email mail@example.com, verify it, change it to the mail another@domain.com and stay verified and enabled. This may lead to having accounts addressed to totally different emails, that were verified. Note, that this way one is not able to take over any existing account (guest or normal one). ### Patches Patch has been provided for Sylius 1.6.x and newer - 1.6.9, 1.7.9, 1.8.3. Versions older than 1.6 are not covered by our security support anymore. ### Workarounds If for whatever reason you are not able to upgrade your application version, you may resolve this issue on your own by creating a custom event listener, which will listen to the `sylius.customer.pre_update` event. You can determine that email has been changed if customer email and user username are different. They are synchronized later on. Pay attention, to email changing behavior for administrators. You may need to skip this logic for them. In order to achieve this, you should either check master request path info, if it does not contain `/admin` prefix or adjust event triggered during customer update in the shop. You can find more information on how to customize the event h
sylius/sylius
source listedECOSYSTEM: introduced 1.8.0; fixed 1.8.3
### Impact The user may register in a shop by email mail@example.com, verify it, change it to the mail another@domain.com and stay verified and enabled. This may lead to having accounts addressed to totally different emails, that were verified. Note, that this way one is not able to take over any existing account (guest or normal one). ### Patches Patch has been provided for Sylius 1.6.x and newer - 1.6.9, 1.7.9, 1.8.3. Versions older than 1.6 are not covered by our security support anymore. ### Workarounds If for whatever reason you are not able to upgrade your application version, you may resolve this issue on your own by creating a custom event listener, which will listen to the `sylius.customer.pre_update` event. You can determine that email has been changed if customer email and user username are different. They are synchronized later on. Pay attention, to email changing behavior for administrators. You may need to skip this logic for them. In order to achieve this, you should either check master request path info, if it does not contain `/admin` prefix or adjust event triggered during customer update in the shop. You can find more information on how to customize the event h
sylius/sylius
source listedECOSYSTEM: introduced 1.0.0; fixed 1.6.9
### Impact The user may register in a shop by email mail@example.com, verify it, change it to the mail another@domain.com and stay verified and enabled. This may lead to having accounts addressed to totally different emails, that were verified. Note, that this way one is not able to take over any existing account (guest or normal one). ### Patches Patch has been provided for Sylius 1.6.x and newer - 1.6.9, 1.7.9, 1.8.3. Versions older than 1.6 are not covered by our security support anymore. ### Workarounds If for whatever reason you are not able to upgrade your application version, you may resolve this issue on your own by creating a custom event listener, which will listen to the `sylius.customer.pre_update` event. You can determine that email has been changed if customer email and user username are different. They are synchronized later on. Pay attention, to email changing behavior for administrators. You may need to skip this logic for them. In order to achieve this, you should either check master request path info, if it does not contain `/admin` prefix or adjust event triggered during customer update in the shop. You can find more information on how to customize the event h
03 / Response
What to do next
- vendor patch
The original advisory lists fixed boundaries 1.7.9 for sylius/sylius. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 1.8.3 for sylius/sylius. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 1.6.9 for sylius/sylius. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- investigate
Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. FIRST EPSS
A fixed release is not deployment evidence.
Check current vendor support and compatibility. After making a change, verify the deployed build and relevant runtime conditions. Keep the evidence, owner and time. An updated lockfile alone does not prove what is running.
04 / Limits
What this report cannot establish
- Customer inventory, deployment, reachability and exploitation have not been inspected.
- NVD lastModified does not establish freshness of every associated CPE record.
05 / Provenance
Sources you can inspect
Each assertion retains its source. Mirrored records may repeat one underlying publisher; additional links are not independent corroboration.
- GHSA-6gw4-x63h-5499 ↗
GitHub Advisory Database via OSV · vendor advisory
Observed . GitHub-origin advisory, CC-BY-4.0; OSV is an aggregate copy, not independent corroboration.
- CVE-2020-15245 ↗
NIST National Vulnerability Database · official catalog
Observed . This product uses data from the NVD API but is not endorsed or certified by the NVD.
- CVE-2020-15245 ↗
FIRST EPSS · official catalog
Observed . FIRST EPSS; probability of exploitation in the next 30 days, not local compromise. Dataset date/model retained; FIRST services terms apply.
Public revision history
Only published revisions appear here. Routine fetches do not create a material-change event.
- Revision 4 ·
Dated EPSS estimate updated; this is not a new disclosure or proof of exploitation.
- Revision 3 ·
Dated EPSS estimate updated; this is not a new disclosure or proof of exploitation.
- Revision 2 ·
Source facts changed; compare the preserved prior revision.
- Revision 1 ·
First indexed by Null; source disclosure date is shown separately.