The common inherent possible security issues from adding Unicode support (not specific to UTF-8) come from the increased potential for visual spoofing, and issues coming from normalization mismatches.
Visual spoofing: say you have a forum with a user named "admin" that everyone knows to trust. Someone else could register a user account named "аdmin" (the first letter is the cyrillic letter a), and trick others into thinking they were the site admin. This is mostly a technique for social-engineering: it's unlikely that any software will mix up the users. (This specific example could be partially addressed by having the site add special formatting or flair near the admin's name, making profile names be links to profile pages which show the user's activity history and join date, etc., so users could identify others in ways besides their visible forgeable name. This is a more general issue that isn't exclusive to unicode support: users could also name themselves other misleading names like "<site> Support", "admin " with a space, "admim", etc.)
Normalization: certain characters like "ö" can be represented in multiple ways. It could either be the single character U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS), or the two characters U+0061 U+0308 (LATIN SMALL LETTER O + COMBINING DIAERESIS). Normalization is the process of converting all text to the combined or decomposed form. If you consistently never use normalization or always use normalization, then you won't run into issues. However, if you sometimes do, you can have security issues:
For example, OS X normalizes unicode in filenames. Say you had a website without any normalization-related code running on an OS X server where whenever a user registered, a file was created with their name, and you used a database without any normalization to keep track of usernames that were already registered in order to prevent names being re-registered. If you had a user named "foö" (using U+00F6), then someone else could register an account named "foö" (U+0061 U+0308), and the site would allow it but would overwrite the file created by the first "foö" user. To solve this, you would either need to make your application normalize consistently throughout the whole application, or you would need to check for collisions whenever you cross some boundary that does normalization differently (when a user registers and you need to make a file for them, open the file in exclusive mode so that it will fail if the file already exists, and you can block the new user from being registered).