NPM security advisory

TL;DR: If you are using NPM and have installed the package eslint-scope 3.7.2, we recommend you to revoke your MyGet access tokens.

Security Advisory

At MyGet, we’re always closely monitoring security events in the package management space, and we want you to be aware of a vulnerability incident that hit npm users today. The full incident report can be read on the status page.

A well-known popular npm package, eslint-scope (version 3.7.2) was published without authorization, and apparently contained malicious code that attempted to steal npm login tokens.

It has been unpublished from, and a post-mortem has been published by the eslint team.

We have scanned all MyGet feeds for this package, and have informed affected feed owners personally.

Nevertheless, if you are using NPM and are consuming the eslint-scope package, no matter whether from directly or proxied through MyGet, we recommend to:

  • Verify your feeds for affected packages, and remove them.
  • Revoke or regenerate your MyGet access tokens at once. Access tokens can be managed from your MyGet profile page.
  • Update your MyGet credentials from your MyGet account page.
  • If you push packages to via an upstream source, you’ll need to update your access token in the upstream source configuration.

Happy packaging!

Author: Xavier Decoster on 13 Jul 2018

Accidental account deleted notification - what happened

On May 17, 2018, a subset of 2.500 MyGet users accidentally received an automated e-mail informing their account was deleted due to inactivity (while no user data was in fact, removed). We want to apologize for this accidental e-mail, and detail our investigation into why this happened.

Since a couple of weeks, we are tracking inactive users on our free plan, for two reasons. First, of course, it would be nice if those users become active again, and maybe even upgrade to a paid subscription. Second, as part of our efforts in ensuring user privacy, we want to ensure we don’t keep user data around for users who are no longer using our service.

There are two processes involved in this, let’s call them Flag and RemoveIncomplete.

The Flag job checks existing users and their subscription, and informs inactive users how they can keep their account active (or let it expire after a further 30 days of inactivity). When looking at the accidental e-mails, they all looked like they were sent by the Flag job, which is also what we communicated with affected users on May 17, 2018.

Further investigation learns the RemoveIncomplete was responsible for these accidental e-mails.

Let’s look at something else first. When clicking the Microsoft Account or GitHub identity provider on the MyGet login screen, we create a temporary profile without a username. The first step after the first login is for our user to pick their desired username. If they don’t, the user profile is deemed “incomplete” as there is no username attached to it. It’s this type of profiles the RemoveIncomplete job removes.

Under the hood, this job uses the same code we use to remove a user profile when requested by the user. As a confirmation, we send the user an e-mail when removal is finished. It’s this type of e-mail that was sent by the RemoveIncomplete job.

Users all of a sudden received e-mail stating their account was deleted and panicked. Adding to the confusion, no username was mentioned in the e-mail.

The RemoveIncomplete job successfully removed incomplete user profiles. It should never send out e-mails, but a recent code change had disabled that check. Which translated into many users getting an “account was removed” e-mail without the username being included (as there is no username in an incomplete user profile).

So why did some existing users receive an e-mail if it’s only incomplete user profiles being removed? The answer to that is fairly simple. All of the users that received the accidental e-mail, received it because they had an incomplete profile next to their actual profile:

  • User profile id:12345, username:<null>, - deleted and e-mailed
  • User profile id:54321, username:example, - unaffected and still active

In this case, user id:12345 was removed (because there was no username attached to it), and accidentally sent an e-mail. User id:54321 is still active and unaffected.

We again want to apologize for the confusion this caused, and have updated our codebase to not send out e-mails in this case, and added relevant unit tests to prevent this from happening again.

Happy packaging!

Author: Xavier Decoster on 28 May 2018

MyGet symbol server helps mitigate CVE-2018-1037

On April 10, 2018, Microsoft released a security update, CVE-2018-1037 , describing how Visual Studio can improperly disclose limited contents of uninitialized memory while compiling program database (PDB) files.

The memory leaked is limited to typically low-risk variables used in the application build environment, and only information that the Visual Studio executable uses when compiling projects. If your PDB/symbol files are shared publicly, this information could be extracted.

Visual Studio versions have been patched, so we recommend installing the latest security updates for your Visual Studio version.

While the security issue is unlikely to be exploited, KB4131751 was released to verify existing PDB files. Symbols served from MyGet symbols feeds are automatically checked for this vulnerability, and updated when necessary.

This security fix is gradually rolling out across all of our deployments.

Happy packaging!

Author: Maarten Balliauw on 18 Apr 2018

Deprecating Facebook, OpenID and StackExchange login to MyGet

TL;DR: MyGet will retire Facebook, OpenID and StackExchange login to MyGet on March 9, 2018.

Historically, MyGet has been using the Microsoft Azure Access Control Service (ACS). It allowed our users to easily create a MyGet account from an existing third-party login system, like Microsoft Account, Google Account, GitHub authentication, …

With Microsoft sunsetting the ACS service and having to migrate to a different service, we are re-evaluating which third-party login types we want to provide in the future. Right now, only a handful of our users are actively making use of the Facebook, OpenID and StackExchange authentication providers, which prompted us to retire these three providers. MyGet will retire Facebook, OpenID and StackExchange login to MyGet on March 9, 2018.

Affected users have been notified about this via e-mail.

If you are making use of Facebook, OpenID or StackExchange to login to MyGet, it’s always possible to use another third-party identity provider, like Google Account or GitHub. You can link these via your MyGet user profile.

Of course, you can always keep using your MyGet username/password combination to login to MyGet.

Happy packaging!

Author: Maarten Balliauw on 22 Feb 2018

MyGet 2017.2 Release Notes

We are happy to announce MyGet 2017.2 was released on December 13, 2017! Full release notes are available from our docs.


Next to some new features and many fixes, this 2017.2 release of MyGet again adds some new functionality to the service.

Major highlights of this release are:

  • We added PHP Composer support, and welcome PHP developers to the MyGet family! (Announcement | Docs)

    In fact, this also resulted in a bug fix on Composer itself (which is now merged, yay!) - composer/composer#6717 will be part of Composer 1.5. Happy to contribute back!

  • In light of upcoming EU General Data Protection Regulation (EU GDPR), which will be enforced in May 2018, MyGet is taking proactive action to verify we are compliant, and take corrective measures if we spotted anything that is not compliant, or questionable (typical grey area in legislation). Being a EU-based company, we take privacy and security very seriously! As such, we focused in this release to ensure that:

    • user sign-ups by default opt-out of marketing communications or newsletters; unless the user explicitly takes positive action by ticking the checkbox to opt-in (which of course we do recommend, as we try to keep you informed about evolutions and guidance in the package management space)
    • first-time visitors see a proper cookie consent banner, requiring so-called double consent from the user (in other words: we ask you to explicitly accept/deny non-essential cookies instead of the automatic consent with cookies you see elsewhere on the Internet)
    • we verified our usage of essential and non-essential cookies and ensure we comply to GDPR in the way we handle these
    • we don’t retain any personally identifiable information (PII) data longer than necessary and only use it for the purposes intended (full details in our Terms of Service and Privacy Policy)

    As data protection is critical, MyGet can help organizations in protecting them against potential vulnerabilities imposed by third-party or open source dependencies using the built-in vulnerability report on each feed. More GDPR-specific changes are coming to MyGet as we continuously deploy our services, and will be aggregated in the 2018.1 release notes.

  • Another big theme we focused on lately is auditing. Similar to our activity streams, we made security related events accessible in an easy to use audit log to MyGet Enterprise administrators. (Announcement) In addition, we allow an export of these audit logs into a downloadable .csv file containing up to 25.000 entries.


Full release notes with a list of all features and fixes are available from our docs.

We love hearing from you, so keep that feedback coming! MyGet is built for you!

Happy packaging!

Author: Xavier Decoster on 13 Dec 2017

Inspecting audit logs in MyGet Enterprise

A couple of weeks back, we released an audit log viewer on MyGet Enterprise. Administrators of a MyGet Enterprise plan can inspect every action that happens on their MyGet instance and see who did what, when, and where.

From the MyGet Enterprise administration dashboard, all actions performed on the Enterprise installation can be consulted:

The list of audit entries is searchable and can be exported to a CSV file so additional querying can be done in, for example, Excel. Details for each audit entry can be consulted and display the action that was performed, who performed it, and where it was executed. We can also see the location the user performed the action from, including the IP address (last octet always 0 for privacy reasons).

With audit logs available on MyGet Enterprise, we are confident MyGet can help larger teams and enterprises with auditing and dependency lifecycle management.

Happy packaging!

Author: Maarten Balliauw on 16 Nov 2017

PHP Composer packages just arrived on MyGet

MyGet supports hosting private PHP Composer packages

Good news everyone! We just shipped PHP Composer support on MyGet! If you are building PHP applications and libraries, you can now package them and add these to your MyGet feeds.

PHP Composer support is available for all MyGet accounts - check the PHP Composer features described in our documentation

Which features are available?

We currently support almost all features we have available for other package managers. Of course you can upload your own packages (via the web UI as well as via a curl POST) or packages from upstream repositories like Packagist.

Packages can be consumed in any PHP Composer-based project. It’s possible to proxy upstream repositories into your MyGet feed. You can manage permissions and users, inspect package licenses and vulnerabilities, …

Build services are supported as well: as long as there is a composer.json in your repository, we’ll run tests against it, package it up and make it available as a PHP Composer package on your Myget feed.

Sounds great! How do I get started?

Quite easy: head over to and sign in (or register). You can then create a feed and start adding packages. Our getting started documentation has some more details on how to upload your first PHP Composer package to MyGet.

We’re really excited about introducing PHP Composer support on MyGet! You can now use MyGet to securely host and collaborate on NuGet, symbols and sources, Chocolatey, PowerShell, NPM, Bower, Maven, PHP Composer and VSIX packages.

Happy composing!

Author: Maarten Balliauw on 11 Sep 2017

Using a private MyGet feed with JetBrains Rider

image_thumb2JetBrains just released a new .NET IDE: Rider. At MyGet, we’ve been using Rider for our internal development since it was announced. So far, we have really enjoyed this IDE built around ReSharper! And since it comes with a lightning-fast NuGet client, let’s see how we can consume packages from a MyGet feed.

Adding a MyGet feed package source

The first step in connecting Rider to a MyGet feed is adding it as a package source. We can do this using NuGet.exe (via good old NuGet.config), or from within Rider. From the NuGet tool window, open the Sources tab. This will show us all of the NuGet configuration files that are in play, and a list of all feeds configured.


From here, we can add our MyGet feed (or edit an existing entry). We will have to give our feed a name so we can easily recognize it in Rider, and the URL to our feed. This URL can be found on the MyGet feed details page after logging in to


The NuGet client in Rider supports working with public and private MyGet feeds. While Rider supports using pre-authenticated feeds as well as feeds that require entering credentials, we recommend using the latter. Rider safely stores our MyGet username/password in its password store, which is based on KeePass.

Using MyGet together with JetBrains Rider makes it possible to develop .NET applications and let your development team consume both public and private packages hosted securely on MyGet.

Happy packaging!

Author: Maarten Balliauw on 04 Aug 2017