A security researcher found a flaw in Instagram's website that caused thousands of users' email addresses and phone numbers to be exposed online for several weeks, it was revealed on Thursday.
David Stier, a data scientist and business consultant, told CNET the website source code for some Instagram user profiles included the account holder's contact information whenever it loaded in a web browser.
Although the contact information was available in Instagram's mobile app if users chose to reveal it in their profile, it was never displayed on the desktop version of the Instagram website, so it's unclear why the details were exposed.
The leaked contacts are said to have come from thousands of accounts belonging to private individuals, including minors, as well businesses and brands. Stier alerted Instagram to the problem shortly after discovering it in February, and the photo-focused social platform issued a patch in March.
According to Stier, including the details in the source code could have let hackers scrape the data from the website relatively easily and use it to compile a database listing the contact information of thousands of Instagram users.
A similar data haul may have already occurred. On Monday it was revealed that a database containing contact information for millions of Instagram influencers, celebrities, and brand accounts had been leaked online.
The records included public data pulled from Instagram, such as profile picture, biography, and follower numbers, but also private contact information like phone numbers and email addresses.
The database was initially uploaded and shared by Mumbai-based social media marketing firm Chtrbox, a company that pays Instagram influencers to share sponsored content. Though uploaded by Chtrbox, the database included info from influencers who have never worked with the company.
In a statement, Chtrbox said the information in its database wasn't private and that it didn't source the information through unethical means.
Instagram parent company Facebook said on Monday that it was investigating the Chtrbox database. "We're also inquiring with Chtrbox to understand where this data came from and how it became publicly available," said Facebook.
A similar privacy befell the social media platform in August 2017, when a bug related to an Instagram API allowed hackers to breach multiple high-profile Instagram accounts belonging to celebrities.
![Apple Watch Ultra 3 Hits New Low Price With Amazon's $299 Discount [Updated]](https://images.macrumors.com/t/BXKI27vT0hWfumJQpYzf41rH3Mw=/112x112/article-new/2026/10/apple-watch-ultra-3-milanese.jpeg)
Top Rated Comments
Everyone sane: *begins taking bets on how long until the next privacy issue is discovered*
I am not at all surprised, though.
I am one of a small handful of developers who still answer questions on the jQuery developer forums. jQuery is a popular but rapidly-fading Javascript library that was created primarily to "normalize" the differences between browsers so that devs don't have to code "if this browser, do this, if that browser do that...". Instead, jQuery provides it's own API and if you use their API then it deals with the differences between browser. Rapidly becoming a Thing That Is Not Needed.
Anyhoo, I am shocked at the low level of competency on the part of the (almost always overseas) frontend devs for major Fortune 500 companies. Like, for example, the web site for a major U.S. cell phone provider that I shall not name. You'll have to cycle through the alphabet to guess, but you won't have to go very far. ;)
So, first off, how do I know that they are working for major Fortune 500 companies? Because they've repeatedly failed to reduce their examples to the minimum needed to show the problem, and just post links to their development site - which is typically open to the Internet with no security. If somebody is willing to help them, they will have to dig through mountains of code - like 50 or more JS files being loaded, with redundant plugins left by the previous devs who were hired to do Just One Thing and then moved on to other jobs for other companies. They just keep adding layer after layer of crap. And another dozen tracking scripts, etc.
Anyway, there's their logo, and say an order form for for service, or for the latest iPhone or whatnot, and they've posted a link to their example page and usually it's accessible without a password, though sometimes it needs one, which of course they post openly in an open forum.
So, I COMMONLY see things like price calculators that are being relied-upon by the backend (they have inadvertently created their very own "name your own price tool"!), and it's not uncommon for the devs to not understand that Javascript running in a browser is NO MEASURE OF SECURITY. The only reason anyone should be doing any kind of price calculations or form validations in a web page is as a convenience to the user, to avoid a trip back and forth to the server. Where the validations MUST be done again, but often never are.
It is very common to see posted PHP, C# code, etc. often with no understanding on the part of the dev that we can't help them with that - it's a jQuery forum, not a forum for some random server language. And, at the same time, no understanding that, say, the PHP code runs on the server, and the Javascript code runs in the browser. Chalk that up to the awful historical design of PHP where you can (you don't HAVE to, and this style is discouraged today) mix server and browser code in the same file. It's not uncommon for these devs to just not get it that the server is treating their file as a template, and generates HTML on the server to send to the browser, and the generated HTML (generated by the PHP code) is sent rather than the PHP.
Since we often see PHP/C#/Cold Fusion/whatever code, that means we also see their (common) SQL injection vulnerabilities and other horrors of poor or no security in server code.
I can see the described leakage easily happening because a dev made a query that returned columns that should never have been included in the page and/or the dev somehow thought there's no issue with including some extra data that "the user will never see". You know, because it is "hidden". Hidden, yes, to the casual user, but not to anybody who knows how to use the web inspection/debugging tools present in every desktop browser. Or to a scraper/crawler, which is not limited to seeing just the "visible" elements on a page.
Somebody "might have made a copy". No, it is certain that somebody made a copy. There are certainly multiple copies of the data now in scrapers archives, and they probably do not even know what they have. A scraper is just a robot - it will scrape whatever it finds and squirrel it away. Probably later, an algorithm or a human will comb through it to see what might be "interesting".
Front-end development practices, as done by many top companies, is just absolute crap. The companies piece it out to the cheapest bidder, and there is often no continuity. It gets handed off from one developer to another and again and again and again, and each adds their own layer of crap and leaves their own footprints to the mess.
Beyond that, it is OBVIOUS that many of these devs are getting their information from 10-20 year-old books (which is why I now dispose of old development books rather than them them to a charity store), outdated blogs and tutorial sites, etc. Search engines and SEO have a surprising influence on this, BTW. Because sites that work their way to the top continue to stay there for many years after they have ceased to be useful. There are so many "frozen" dev tutorial sites that just have obsolete information but were once the top reference, and the search engines do a poor job of "expiring" their rankings.
I have to admit, I often Google for answers. But I CHECK THE EXPIRATION DATE. Usually I will include a data constraint in my searches and then check any dates in the blog or tutorial, etc. to insure I am getting fresh results, and not some 10-year-old advice. You don't know how many of these devs I have to point toward MDN, CSS-Tricks, jQuery Learning Center (on the VERY SAME SITE they are posting on...) and they had no clue that these sites existed and are the best references on the development they are doing.
What this researcher uncovered is just the tip of the iceberg. It is not an anomaly. It is endemic.
Edit: It's probably not fair to place the blame on front-end developers. Much of it can be blamed on the scourge known as "full-stack development". This is the fantasy that one person can do it all - front end, back end, database, security, etc. So, you have devs that know a little bit of that, a little bit of that, much of it outdated. As well as the fantasy that developers are fungible - you can just pass off bits and pieces of functionality to whatever random dev is available or can be hired the cheapest from an online virtual sweat-shop to implement a feature and you will somehow magically wind-up with something coherent.
And that, my friends is how sausage.... er, many of the highest profile websites - are too often made.
By now everyone should know that those big cooperations care more about ad revenue and sale of personal data then about protecting the privacy of their user base - there is just no money in protecting the privacy and apparently users still stick with them - so no harm done in their view point.