Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
19 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Malicious algorithms can potentially access other algorithms input and output files. Patches Todo Workarounds Verify and restrict the algorithm containers that are allowed to run on your node. See here on how to do this. References https://docs.vantage6.ai/usage/running-the-node/security For more information If you have any questions or comments about this advisory: Email us at vantage6@iknl.nl
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Vantage6 currently provides an initial user with username root and password root. This is not ideal for the following reasons: - Attackers know that almost all vantage6 servers have a user with username root that probably has admin rights - The initial password is very weak and it is possible that administrators forget to reset it. Patches No Workarounds It is possible to delete the root user after it has been used to create other users References We could consider doing this like mongodb Additional info Luis uses the following patch to mitigate it:
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If an attacker hacks into a vantage6 user's email account, they can 1) reset the password via email and then 2) reset the 2FA token via email. This way they reduce 2FA to 1FA (email access). Note that most email providers require 2FA to access email, so this issue is not very likely to cause issues. Proposed solution Many web apps do not provide functionality to reset 2FA token (probably for this reason), but provide recovery codes as well. It would be better to provide these recovery codes to the user 1 time and then delete the option to reset it. An alternative may be to only let server administrators reset 2FA token. However, this has as disadvantage that a hacked email account may send messages to the server admin to reset them, which they may fall for. Patches No Workarounds No
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users can reset their MFA token via API routes that send them an email. Currently the number of emails that is sent is not limited. This gives attackers the option to flood someones mailbox with a lot of emails, and would have adverse effects on the SMTP server which may be seen as spam sender. Note resetting the MFA token requires a correct password, so the potential impact for this is very low. Patches No Workarounds No
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If attacker gets access to an authenticated session, they can try to brute-force the user password by using the change password functionality: they can call that route infinitely which will return the message that password is wrong until it is correct Patches This issue has been patched in version 4.11.0 Workarounds None
Recommended action: Upgrade to 4.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Collaboration administrators can add extra organizations to their collaboration. When doing that, they extend their influence: for instance, for organizations that they include, they can then create new users for which they know the passwords, and use that to read task results of other collaborations that that organization is involved in. Only relatively trusted users - with access to manage a collaboration - are able to do this, which reduces the impact. Patches No Workarounds No
Recommended action: Upgrade to 4.5.0rc3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Much like https://github.com/vantage6/vantage6/security/advisories/GHSA-45gq-q4xh-cp53, it is possible to find which usernames exist in vantage6 by calling the API routes /recover/lost and /2fa/lost, which send emails to users if they have lost their password or MFA token. Usernames can be found by assessing response time differences, and additionally, they can be found because the endpoint gives a response "Failed to login" if the username exists. Patches No Workarounds No
Recommended action: Upgrade to 4.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vantage6 server has no restrictions on CORS settings. It should be possible for people to set the allowed origins of the server. The impact is limited because v6 does not use session cookies Patches No Workarounds No
Recommended action: Upgrade to 4.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There are no checks on whether the input is encrypted if a task is created in an encrypted collaboration. Therefore, a user may accidentally create a task with sensitive input data that will then be stored unencrypted in a database. Workarounds This is not an issue with the normal workflow, only if e.g. a user with the python client sets encryption to the wrong value.
Recommended action: Upgrade to 4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It is possible to find out usernames from the response time of login requests. This could aid attackers in credential attacks Workarounds No
Recommended action: Upgrade to 4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Nodes and servers get a ssh config by default that permits root login with password authentication. In a proper deployment, the SSH service is not exposed so there is no risk, but not all deployments are ideal. The default should therefore be less permissive. We will probably opt to completely remove the ssh option as it is only used for debugging. Later, we can add a debug mode where we can activate it if necessary. Workarounds Remove the ssh part from the docker file and build your own docker image
Recommended action: Upgrade to 4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authenticated users could inject code into algorithm environment variables Workarounds No
Recommended action: Upgrade to 4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a collaboration is deleted in vantage6, the linked resources (such as tasks from that collaboration) are not properly deleted. This is partly to manage data properly, but also to prevent a potential (but unlikely) side-effect, where if a collaboration with id=10 is deleted, and subsequently a new collaboration is created with id=10, the authenticated users in that collaboration could potentially see results of the deleted collaboration in some cases, resulting in information disclosure.
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Malicious users may try to get access to resources they are not allowed to see, by creating resources with integers as names. One example where this is a risk, is when users define which users are allowed to run algorithms on their node. This may be defined by username or user id. Now, for example, if user id 13 is allowed to run tasks, and an attacker creates a username with username '13', they would be wrongly allowed to run an algorithm. There may also be other places in the code where such a mixup of resource ID or name leads to issues. The best solution we see is therefore to check when resources are created or modified, that the resource name always starts with a character. Patches To be done, probably in v3.9 Workarounds None
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The endpoint /api/collaboration/{id}/task is used to collect all tasks from a certain collaboration. To get such tasks, a user should have permission to view the collaboration and to view the tasks in it. However, currently it is only checked if the user has permission to view the collaboration. Patches No Workarounds None References None For more information If you have any questions or comments about this advisory: Email us at vantage6@iknl.nl
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
What We are using pickle as default serialization module but that has known security issues (see e.g. https://medium.com/ochrona/python-pickle-is-notoriously-insecure-d6651f1974c9). In summary, it is not advisable to open Pickles that you create yourself locally. In vantage6, algorithms use pickles to send aggregated data around and to pack algorithm input or output. All of the Python algorithms that use the wrappers with default serialization are therefore vulnerable to this issue. Solution: we should use JSON instead Impact All users of vantage6 that post tasks with algorithms that use the default serialization. The default serialization is used by default with all algorithm wrappers. Patches Not yet Workarounds Specify JSON serialization
Recommended action: Upgrade to 4.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
From issue: Problem description Currently, the refresh token is valid indefinitely. This is bad security practice. Desired solution The refresh token should get a validity of 24-48 hours. Additional context When implementing this, also check that the refresh token returns a new refresh token When implementing this, also adapt the UI so that it logs out if refresh token is no longer valid. When implementing this, ensure that nodes refresh their token periodically so that they do not have to be restarted manually. Impact Patches None available Workarounds None available
Recommended action: Upgrade to 3.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Assigning existing users to a different organization is currently possible. It may lead to unintended access: if a user from organization A is accidentally assigned to organization B, they will retain their permissions and therefore might be able to access stuff they should not be allowed to access. Patches Update to 3.8.0 Workarounds None References None For more information If you have any questions or comments about this advisory: Email us at vantage6@iknl.nl
Recommended action: Upgrade to 3.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact We are incorporating the password policies listed in https://github.com/vantage6/vantage6/issues/59. One measure is that we don't let the user know in case of wrong username/password combination if the username actually exists, to prevent that bots can guess usernames. However, if a wrong password is entered a number of times, the user account is blocked temporarily. This way you could still find out which usernames exist. Patches Update to 3.8.0+ Workarounds No References https://github.com/vantage6/vantage6/issues/59 For more information If you have any questions or comments about this advisory: Email us at vantage6@iknl.nl
Recommended action: Upgrade to 3.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.